Назад | Перейти на главную страницу

Конфигурация безопасности Apache - Ubuntu 12

Я использую стек LAMP в Ubuntu 12, основная функция которого - обслуживание API на основе PHP.

Есть только один файл, который я хочу показать публике: api.php

Он должен ссылаться на файл конфигурации, который у меня есть в /cfg/api-config.php который содержит пароли db, чтобы API мог писать в базу данных и т. д.

Так что я хочу только api.php быть "обслуживаемым" Apache и опубликованным.

Файл конфигурации, который я помещаю в / cfg, должен быть доступен для чтения api.php, но не для всех, кто может посетить сайт.

У меня нет .htaccess, просто httpd.conf настроен как показано ниже.

<VirtualHost *:44448>
    DocumentRoot "/api"
    ServerName localhost:44448
    ServerAlias Server.local
    DirectoryIndex index.html
    CustomLog "/var/log/apache_access.log" combined
    ErrorLog "/var/log/apache_error.log"

    SetEnv APPLICATION_ENV development
    php_flag magic_quotes_gpc off

    <Directory "/api">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

Разрешения на моем /cfg и /api папки: drwxr-xr-x и разрешения на мой конфиденциальный файл конфигурации с паролем базы данных, расположенный в /cfg/api-config.php является -rw-r--r--

Мне было интересно, может ли кто-нибудь сказать мне, правильно ли это настроено и безопасно?

Посредством чего:

A) Все файлы, кроме /api/api.php не являются общедоступными, и доступ к файлам моих серверов невозможен.

Б) Конфигурационный файл с паролями для db (для api) тоже не читается никем, посещающим сайт?

Я попытался проверить это, создав новую папку в /cfg с участием chmod 777, и я не могу получить к нему доступ, и это хорошо!

У вас есть два файла (предположим, что они находятся в / var / www)

  • /var/www/api/api.php
  • /var/www/cfg/api-config.php

Прежде всего, ограничьте доступ к / cfg с помощью apache (это гарантирует, что никто не сможет получить к нему доступ из http) и разрешите доступ к / api:

<Directory /var/www/api>
    Options None
    AllowOverride None
    Order allow,deny
    Allow from all
<Directory>

<Directory /var/www/cfg>
    Options None
    AllowOverride None
    Order allow,deny
    Deny from all
<Directory>

Затем ограничьте свой php с помощью open_basedir:

open_basedir = /var/www/api:/var/www/cfg

(добавьте сюда / tmp, session и другие каталоги, если они вам нужны)

Затем измените режим доступа к каталогу / var / www / cfg и файлу /var/www/cfg/api-config.php (при условии, что ваш пользователь apache - www-data):

  chown -Rv root:root /var/www/{cfg,api}
  chmod -v 711 /var/www/cfg
  chmod -v 755 /var/www/api
  chmod -v 644 /var/www/api/api.php /var/www/cfg/api-config.php

Используя 711 on / cfg, вы гарантируете, что никто не сможет прочитать (перечислить) содержимое каталога, в то время как все еще может читать api-config.php (вам это нужно для чтения файла с помощью PHP)

В дополнение к приведенным выше предложениям я бы рекомендовал удалить доступ на запись к любым файлам / папкам в вашем DocumentRoot, принадлежащим вашему пользователю apache. (например, ваш файл api.php). Предполагается, что api.php (или все, что он вызывает) не должен ничего записывать на локальный веб-сервер. Это должно помочь предотвратить запись нежелательных файлов на ваш веб-сервер.

Похоже, вы сделали одну важную вещь: поставили /cfg/api-config.php вне вашего DocumentRoot. Если /cfg не находится в пространстве URL, то пользователи веб-сайта не могут его прочитать. Это самая простая из возможных мер предосторожности.

Могут ли пользователи по-прежнему читать этот файл? Конечно, если вы нарушите конфигурацию где-нибудь еще (установив Alias или RewriteRule в файл, например), или если приложение делает что-то глупое, например, выводит содержимое файла. Настоящую проблему вызывают уязвимости приложений: приложение должно иметь возможность читать файл, и чем сложнее приложение, тем больше вероятность, что в нем есть скрытая уязвимость. Но что касается конфигурации Apache, я думаю, что все готово.

Сначала я бы изменил права доступа к вашему cfg и файлам, которые в нем находятся. Если вы храните в нем настройки БД, то это доступ для чтения, а доступ для записи следует убрать. Приятно иметь вашу Apache HTTP Daemon - среду, настроенную в безопасности, но это еще один уровень безопасности. Ваша PHP-установка выполняется в пользовательском контексте вашего HTTP-демона, поэтому я лично бы даже удалил доступ для чтения для группы. Интересно, какие тесты вы проводили? Папка cfg - кажется, не находится под вашим DocumentRoot, поэтому на первый взгляд кажется, что она недоступна для вашего HTTP - сервера. Но люди, пытающиеся взломать вашу установку, не будут полагаться на такой подход. У вас есть AllowOverride All Order allow, запретить Allow from all в вашей конфигурации, что просто означает: никакого контроля доступа вообще. Вы также указываете FollowSymLinks, который представляет другие воздействия на безопасность. Так что эта установка далеко не безопасна. Вы можете защитить свою cfg-папку, поместив файл .htaccess в DocumentRoot ваших установок. Записи в нем могут надежно защитить доступ как к файлам, так и к каталогам, например

<Файлы RELEASE_NOTES.txt>
заказ разрешить, запретить
отрицать от всех
</Files> (взято из magento - установка)

Если вас интересует влияние FollowSymLinks на безопасность: помните, что PHP работает в контексте вашей установки Apache HTTP Daemon и что PHP может выполнять операции записи в вашей файловой системе. Если PHP-код вставляется в ваше приложение, создавая на нем символические ссылки, чтобы кто-то мог шпионить за вашей файловой системой, просто создавая символические ссылки на части вашей системы, в которых он или она заинтересованы. Размещение простого .htaccess-файла в вашем cfg - каталог формы Разрешить заказ, запретить Запретить от всех удалит возможность просмотра этого каталога через ваш HTTP-демон. Если ваш api.php является передним контроллером вашего PHP - Installation / Webapp, вам следует рассмотреть возможность использования Apache mod_rewrite для перезаписи всех URL-адресов, запрашиваемых для указания на ваш api.php, например

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI}! = / Favicon.ico
RewriteRule ^ api.php [L]

в файле .htaccess, который вы помещаете в каталог / api, который будет направлять все запросы на ваш api.php. например localhost: 44448 / someURL? id = 988 станет внутренним запросом localhost: 44448 / api.php? id = 988.
Чтобы прояснить:
Правила перезаписи не следует использовать для контроля доступа, они в основном предназначены для изменения способа обработки запросов.
Многие PHP-Framework или CMS используют RewriteRules, чтобы иметь центральную точку входа в веб-приложение, в которой загружаются компоненты приложения, могут быть вызваны компоненты маршрутизации и выполняются переводы параметров URL-адреса во внутренние структуры.
Например. Symfony2 переводит параметры Query / и Post в более объектно-ориентированную структуру, инкапсулируя ее в объект.
Symfony2 также использует концепции безопасности, считывая информацию о маршрутизации и конфигурации перед генерацией HTTP-ответа, например, обеспечение того, чтобы аутентификация была выполнена или что у пользователя должна быть правильная роль пользователя для доступа к URL-пути.