7.3. Права доступа

We use cookies. Read the Privacy and Cookie Policy

7.3. Права доступа

В данном разделе нам предстоит познакомиться с основными параметрами файла конфигурации /etc/httpd/conf/httpd.conf. Они отвечают за права доступа, относящиеся к директориям, и имеют следующий вид:

<Directory /var/www/html>

 Order allow,deny

 Allow from all

</Directory>

или, например:

<Location /server-status>

 SetHandler server-status

 Order deny,allow

 Deny from all

 Allow from .your-domain.com

</Location>

Первое объявление задает права доступа к определенной директории на диске (в данном случае /var/www/html), а второе — ограничивает доступ к виртуальной директории (в приведенном примере http://servername/server-status).

Если вы знакомы с HTML (HyperText Markup Language, язык разметки гипертекста) или XML (Extensible Markup Language, расширенный язык разметки), то такое объявление будет вам известно и понятно без дополнительных разъяснений. Для тех, кто не в курсе, я сделаю несколько пояснений на примере директорий. Объявление начинается со следующей строки:

<Directory Путь>

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

</Directory>

Параметры доступа к директории могут быть описаны не только в файле /etc/httpd/conf/httpd.conf, но и в файле .htaccess, который может находиться в указанном каталоге. Сам файл требует отдельного рассмотрения (см. разд. 7.5.1), а сейчас вы должны только знать, что разрешения, указанные в конфигурации Web-сервера, могут быть переопределены.

Теперь рассмотрим, как задаются права доступа. Для этого используются следующие директивы:

? Allow from параметр — определяет, с каких хостов можно получить доступ к указанной директории. В качестве параметр можно использовать одно из следующих значений:

 • all — доступ к директории разрешен всем;

 • доменное имя — определяет домен, с которого можно получить доступ к директории. Например, можно указать domain.com. В этом случае только пользователи этого домена смогут получить доступ к директории через Web. Если какая-либо папка содержит опасные файлы, с которыми должны работать только вы, то лучше ограничить доступ своим доменом или только локальной машиной, указав allow from localhost;

 • IP-адрес — сужает доступ к директории до определенного IP-адреса. Это очень удобно, когда у вашего компьютера есть выделенный адрес, и вы хотите обеспечить доступ к каталогу, содержащему администраторские сценарии, только для себя. Адрес может быть как полным, так и неполным, что позволяет ограничить доступ к директории определенной сетью;

 • env=ИмяПеременной — доступ разрешен, если определена указанная переменная окружения. Полный формат директивы: allow from env=ИмяПеременной;

? Deny from параметр — запрещение доступа к указанной директории. Параметры такие же, как у команды allow from, только в данном случае закрывается доступ для указанных адресов, доменов и т.д.;

? Order параметр — очередность, в которой применяются директивы allow и deny. Может быть три варианта:

 • Order deny, allow — изначально все разрешено, потом первыми применяются запреты, а затем разрешения. Рекомендуется использовать только на общих директориях, в которые пользователи могут самостоятельно закачивать файлы, например, свои изображения;

 • Order allow, deny — сначала все запрещено, вслед за этим применяются разрешения, затем запрещения. Рекомендуется применять для всех директорий со сценариями;

 • Order mutual-failure — исходно запрещен доступ всем, кроме перечисленных в allow и в то же время отсутствующих в deny. Советую использовать для всех каталогов, где находятся файлы, используемые определенным кругом лиц, например, администраторские сценарии;

? 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.

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

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

Данный текст является ознакомительным фрагментом.