Linux глазами хакера

Флёнов Михаил Евгеньевич

Помимо файлов и директорий можно ограничивать и методы HTTP- протокола, такие как GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK. Где тут собака зарыта? Допустим, что у вас есть сценарий, которому пользователь должен передать параметры. Это делается одним из методов POST или GET. Если вы заведомо знаете, что программист использует только GET-метод, то запретите все остальные, чтобы хакер не смог воспользоваться потенциальной уязвимостью в сценарии, изменив метод.

Бывают варианты,

когда не всем пользователям должно быть позволено отправлять данные на сервер. Например, сценарии в определенной директории могут быть доступны для исполнения всем, но загружать информацию на сервер могут только администраторы. Эта проблема легко решается с помощью разграничения прав использования методов протокола HTTP.

Права на использование методов описываются следующим образом:

<limit ИмяМетода>

 Права

</limit>

Как видите, этот процесс схож с описанием разрешений на файлы. Даже права доступа используются те же самые, и размещаются внутри определения директорий (

<Directory>

или

<Location>

), и влияют только на указанный каталог.

К примеру, так можно запретить любую передачу данных на сервер в директории /home:

<Directory /home>

 <Limit GET POST>

Deny from all

 </Limit>

</Directory>

Внутри определения прав для директории /home устанавливается запрет на методы GET и POST.

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

Я всегда сначала закрываю все, что только можно, и только потом постепенно смягчаю права, чтобы все сценарии начали работать верно. Лучше лишний раз прописать явный запрет, чем потом упустить разрешение, которое позволит хакеру уничтожить мой сервер.

7.4. Создание виртуальных Web-серверов

На одном физическом сервере может работать большое количество виртуальных Web-серверов, например, www.your_name.com и www.your_company.com. Это два разных Web-сайта, но они находятся на одном сервере. Такое расположение дает нам следующие преимущества:

□ экономия денег на закупке серверов;

□ эффективное использование каналов связи, если сайты небольшие и нагрузка на сервер невысока;

□ экономия IP-адресов, лимит которых уже давно был бы исчерпан, если бы все сайты находились на выделенных серверах (с внедрением протокола IPv6 эта

проблема будет стоять не так остро). Виртуальные Web-серверы могут иметь как отдельные IP-адреса, так и использовать общий адрес, а различаться будут доменными именами;

□ упрощение администрирования и контроля за безопасностью. Конфигурация Web-сервера и его защита — достаточно сложный процесс, поэтому намного легче настроить и обновлять программное обеспечение одного физического сервера, чем сотни серверов, ресурсы которых используются на 10%.

Для создания виртуального сервера используется формат:

<VirtualHost адрес:порт>

</VirtualHost>

Между этими тегами указываются параметры виртуального сервера. Вот пример описания сервера, адрес которого 192.168.1.1 и порт 80:

<VirtualHost 192.168.1.1:80>

 ServerAdmin admin@your_server.com

 DocumentRoot /var/www/your_server

 ServerName your_server.com

 ErrorLog logs/your_server.com -error_log

 CustomLog logs/your_server.com -access_log common

 <Directory /var/www/your_server/>

AllowOverride none

 </Directory>

</VirtualHost>

Рассмотрим только основные параметры, которые указываются при описании виртуального сервера:

□ 

ServerAdmin

— E-mail администратора, которому будут направляться сообщения об ошибках;

□ 

DocumentRoot

— директория, в которой расположен корневой каталог сайта;

□ 

ServerName

— имя сервера. Если оно не указано, то используется локальный IP-адрес сервера.

Директивы

ErrorLog

и

CustomLog

нам уже знакомы. После этого в нашем примере идет указание прав доступа на директорию /var/www/your_server/, которая является корнем для виртуального Web-сервера. Разрешения можно устанавливать как внутри объявления виртуального сервера, так и вне его.

За более подробной информацией обратитесь к документации по Apache.

7.5. Замечания по безопасности

В конфигурационном файле /etc/httpd/conf/httpd.conf есть несколько директив, которые позволяют управлять безопасностью. Эти же команды можно указывать в файле .htaccess. Давайте их рассмотрим:

□ 

AuthType параметр

— тип аутентификации. В качестве параметра можно использовать одно из значений: Basic или Digest;