Linux глазами хакера - Михаил Флёнов

□ Require параметр — позволяет задать пользователей, которым разрешен доступ к каталогу. В качестве параметра можно указывать:

 • user — имена пользователей (или их ID), которым разрешен доступ к каталогу. Например, Require user robert FlenovM;

 • group — названия групп, пользователям которых позволен доступ к каталогу. Директива работает так же, как и user;

 • valid-user — доступ к директории разрешен любому пользователю, прошедшему аутентификацию;

□ satisfy параметр — если указать значение any, то для ограничения доступа используется или логин/пароль или IP-адрес. Для идентификации пользователя по двум условиям одновременно надо задать all;

□ AllowOverwrite параметр — определяет, какие директивы из файла .htaccess в указанном каталоге могут перекрывать конфигурацию сервера. В качестве параметр можно указать одно из следующих значений: None, All, AuthConfig, FileInfo, Indexes, Limit и Options;

□ AuthName — домен авторизации, который должен использовать клиент при определении имени и пароля;

□ Options [+ | -] параметр — определяет возможности Web-сервера, которые доступны в данном каталоге. Если у вас есть директория, в которую пользователям разрешено закачивать картинки, то вполне логичным является запрет на выполнение в ней любых сценариев. Не надо надеяться, что вы сумеете программно запретить загрузку любых файлов, кроме изображений. Хакер может найти способ закачать злостный код и выполнить его в системе. С помощью опций можно сделать так, чтобы сценарий не выполнился Web-сервером.

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

 • All — все, кроме MultiView. Если указать строку Option + All, то в данном каталоге будут разрешены любые действия, кроме MultiView, который задается отдельно;

 • ExecCGI — разрешено выполнение CGI-сценариев. Чаще всего для этого используется отдельная директория /cgi-bin, но и в ней можно определить отдельные папки, в которых запрещено выполнение;

 • FollowSymLinks — позволяет использовать символьные ссылки. Убедитесь, что в директории нет опасных ссылок и их права не избыточны. Мы уже говорили в разд. 3.1.3 о том, что ссылки сами по себе опасны, поэтому с ними нужно обращаться аккуратно, где бы они ни были;

 • SymLinksIfOwnerMatch — следовать по символьным ссылкам, только если владельцы целевого файла и ссылки совпадают. При использовании символьных ссылок в данной директории лучше указать этот параметр вместо FollowSymLinks. Если хакер сможет создать ссылку на каталог /etc и проследует по ней из Web-браузера, то это вызовет серьезные проблемы в безопасности;

 • Includes — использовать SSI (Server Side Include, подключение на сервере);

 • IncludesNoExec — использовать SSI, кроме exec и include. Если вы не используете в сценариях CGI эти команды, то данная опция является предпочтительнее предыдущей;

 • Indexes — отобразить список содержимого каталога, если отсутствует файл по умолчанию. Чаще всего, пользователи набирают адреса в укороченном формате, например, www.cydsoft.com. Здесь не указан файл, который нужно загрузить. Полный URL выглядит как www.cydsoft.com/index.htm. В первом варианте сервер сам ищет файл по умолчанию и открывает его. Это могут быть index.htm, index.html, index.asp или index.php, default.htm и т.д. Если один из таких файлов по указанному пути не найден, то при включенной опции Indexes будет выведено дерево каталога, иначе — страница ошибки. Я рекомендую отключать эту опцию, потому что злоумышленник может получить слишком много информации о структуре каталога и его содержимом;

 • MultiViews — представление зависит от предпочтений клиента.

Все выше описанные директивы могут использоваться не только в файле /etc/httpd/conf/httpd.conf, но и в файлах .htaccess, которые могут располагаться в отдельных директориях и определять права этой директории.

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

<Files ИмяФайла>

</Files>

Это объявление может находиться внутри объявления прав доступа к директории, например:

<Directory /var/www/html>

 Order allow,deny

 Allow from all

 <Files "/var/www/html/admin.php">

  Deny from all

 </Files>

</Directory>

Директивы для файла такие же, как и для директорий. Исходя из этого, в данном примере к подкаталогу /var/www/html разрешен доступ всем пользователям, а к файлу /var/www/html/admin.php из этой директории запрещен доступ абсолютно всем.

Помимо файлов и директорий можно ограничивать и методы 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 [email protected]_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 администратора, которому будут направляться сообщения об ошибках;