[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Web мастеру, CGI, Perl, PHP, Apache" / Оглавление документа

Советы по конфигурации защиты сервера

Здесь приводятся некоторые полезные советы на установку защиты сервера. Некоторые из них будут общие, другие специфические для Apache.

Доступ к каталогу в котором хранятся log-файлы.

При старте Apache открывает log-файлы как пользователь под которым стартует сервер до переключения на пользователя определяемого директивой User. Любой, кто имеет разрешение на запись в каталог, куда записываются все log-файлы, может добавить произвольные данные к любому файлу в системе, которая доступна для записи пользователю под которым стартует Apache. Так как сервер обычно запускается root, Вы НЕ ДОЛЖНЫ открывать для всех разрешение на запись в каталог в котором хранятся log-файлы, если Вы не хотите, чтобы они имели полномочия root.

Server Side Includes

Server Side Includes (SSI) может быть конфигурирован так, чтобы пользователи могли выполнять произвольные программы на сервере. Одно лишь это должно вызвать дрожь в позвоночном столбе любого системного администратора.

Одно решение состоит в том, чтобы отключить эту часть SSI. Чтобы сделать это, Вы должны использовать опцию IncludesNOEXEC директивы Options .

Non Script Aliased CGI

Разрешение пользователям, на выполнение сценария CGI в любом каталоге должно рассматриваться только если;

1. Вы уверены, что вашим пользователям не напишут сценарий, который преднамеренно или случайно подвергнет вашу систему атаке.
2. Вы полагаете, что защита на вашем сайте не имеет слабых мест.
3. Вы не имеете никаких пользователей, и никто ни когда не посещает ваш сервер.

Ограничение CGI к специальным каталогам дает администрации контроль над тем, что входит в эти каталоги. Это более безопасно чем non script aliased CGI, но только, если пользователям с доступом для записи в эти каталоги доверяют, или администратор не ленится проверять каждый новый CGI сценарий/программу на предмет потенциальных лазеек в безопасности.

Большинство сайтов предпочитают этот подход чем non script aliased CGI.

CGI вообще

Все сценарии CGI выполнятся под одним и тем же пользователем, так что есть вероятность, что возникнут конфликты (случайно или преднамеренно) с другими сценариями, например User A ненавидит User B и пишет скрипт разрушающий базу данных User B's. В Apache 1.2 и выше существует возможность выполнения скриптов под разными пользователями - suEXEC, это код втранслированный в Apache сервер. Другой популярный способ достижения этой цели - CGIWrap.

Ограничение доступа перекрывающее общую установку защиты ...

Чтобы ограничить широкий доступ к определенным каталогам вам придется установить в них .htaccess файлы, которые позволяют изменить наиболее общую конфигурацию защиты. Для этого необходимо ...

В файле конфигурации сервера, поместите

<Directory />
AllowOverride None
Options None
allow from all
</Directory>

Затем выполните установку защиты для специальных каталогов

Это снимет все отмены, включая и доступ ко всем каталогам кроме специально оговоренных.

Защита файлов сервера по умолчанию

Один аспект Apache, который иногда неправильно истолковывается - особенность заданного по умолчанию доступа. Он установлен таким образом, что если Вы не предпринимаете никаких действий по его изменению, сервер все-таки может находить путь к файлу через нормальный URL и отвечать на клиентские запросы. Но в этом таится скрытая угроза.

Для иллюстрации рассмотрим следующий пример:

1.# cd /; ln -s / public_html
2. Обращение к http://localhost/~root/

Это предоставило бы любому клиенту вход в filesystem. Чтобы обойти это, добавьте следующий блок в конфигурацию вашего сервера:

<Directory />
Order deny,allow
Deny from all
</Directory>

Это запретит заданный по умолчанию доступ к filesystem, затем добавьте соответствующие <Directory> блоки, чтобы предоставить доступ к требуемой области. Например,

<Directory /usr/users/*/public_html>
Order deny,allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order deny,allow
Allow from all
</Directory>

Обратите особое внимание на взаимодействие директив <Location> и <Directory>; например, даже если <Directory/> закрывает доступ, то директива <Location/> может отменить этот запрет.

Также будьте осторожны с UserDir директивой; установка ее в что-нибудь вроде "./" имела бы тот же эффект для root, что и в первом примере.

Партнёры:

Хостинг: