Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

Безопасность Apache: управление доступом.

Рубрика: Безопасность -> Защита сервисов
Метки: | |
Среда, 29 июля 2009 г.
Просмотров: 16080
Подписаться на комментарии по RSS

Ранее был рассмотрен HTTP-доступ со стороны клиента, теперь посмотрим на него с другой стороны - со стороны сервера.

     Термины «авторизация» и «аутентификация» часто используются как взаимозаменяемые, но у каждого из них есть свое точное значение. Аутентификация - процесс проверки имени пользователя и пароля пользователя. А авторизация - это проверка полномочий пользователя: есть ли у данного пользователя права доступа к тому или иному объекту, к примеру файлу. Аутентификация часто (но не всегда) представляется первым шагом авторизации.

     Целевыми объектами авторизации, конечно же, являются файлы и каталоги сервера: к примеру, надо создать каталог, доступ к которому разрешен только сотрудникам компании. В данном каталоге будут находиться некоторые важные внутренние документы или же программы, доступные только для сотрудников. В данном случае доступно два метода контроля доступа: проверка имени пользователя/пароля и проверка IP-адреса.

     Начнем с доступа по IP-адресу.


     Доступ по IP-адресу.

     Данный способ позволяет установить IP-адреса отдельных машин или целых сетей, которым разрешен доступ к серверу. К примеру, для разрешения доступа к файлу private.html пользователей внутренней сети х.х.х.х (если Web-сервер нужен только для внутреннего употребления, нужно поместить его во внутреннюю сеть, а не в DMZ) может применяться следующий блок:

<Files private.html>

  Order Deny,Allow

  Deny from All

  Allow from 10.0.0.0/255.0.0.0

</Files>

     Как было сказано ранее, можно задать как один-единственный адрес, так и целую сеть. Надо применять и имена узлов, но это снизит производительность, так как Apache будет претворять двойной DNS-запрос (начально он разрешит имя в IP-адрес, а затем полученный IP-адрес в имя, чтобы убедиться, что полученное имя совпадает с указанным).

     Если же все-таки нужно указать имя узла, тогда рассмотрим следующий пример:

<Files private.html>

  Order Deny,Allow

  Deny from All

  Allow from example.com

</Files>

     Это совсем не то, что нужно: это правило будет совпадать с именами example.com, lan.example.com, sales.example.com, myexample.com и даже cracker.evilexapmle.com - то есть со всеми именами, которые содержат строку «example.com». Чтобы дать доступ только домену (и его поддоменам) example.com, применяется следующий блок:

<Files private.html>

  Order Deny,Allow

  Deny from All

  Allow from .example.com

</Files>

     Доступ по имени пользователя и паролю.

     Ранее были рассмотренны два способа аутентификации пользователя - Basic Authentication и Digest Authentication. Первый способ представляется самым применяемым в силу своей простоты, но и самым небезопасным, так как пароли кодируются с помощью алгоритма Base-64, который легко раскодируется хакером. Второй способ берет за основу алгоритм MD5, что делает его намного безопаснее, однако он более сложен в настройке.

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

     Сейчас, когда современные браузеры (начиная с IE v5.0 и Netscape v7.0) вполне поддерживают Digest-аутентификацию, смысла в употреблении базовой аутентификации нет.

     Синтаксис этих обеих форм аутентификации существенно отличается от директив Deny и Allow, рассмотренных в предыдущем примере. В данном случае используются четыре директивы:

  • AuthName <строка> - название области, которую нужно защитить. Это название будет показано в окне, запрашивающем у пользователя логин и пароль. Это же имя области применяется и для идентификации разных областей (если их несколько).
  • AuthType <Basic|Digest> - определяет применяемый метод аутентификации.
  • AuthUserFile <файл> - файл, который содержит имена пользователей и надлежащие им пароли. Часто применяется имя .htpasswd.
  • Require <valid-user|список пользователей> - кому может быть предоставлен доступ: допустимому пользователю (который указан в файле AuthUserFile и ввел правильный пароль) или только конкретным (перечисленным в директиве) пользователям, при условии, что они тоже указали правильный пароль.

     Пример:

<Directory /var/www/htdocs/private>

  AuthName "Employee Timetables"

  AuthType Basic

  AuthUserFile /var/www/.htpasswd

  Require valid-user

</Directory>

     Файл .htpasswd рекомендуется хранить за пределами каталога DocumentRoot сервера, к примеру, в каталоге /etc/httpd/.htpasswd. Конечно, современные версии Apache блокируют доступ к файлам .htpasswd, но лучше не рисковать. Современные версии Apache содержат директиву, ограничивающую доступ к файлам, начинающимся на .ht:

<Files ~ "^\.ht">

  Order allow,deny

  Deny from all

  Satisfy all

</Files>

     Опции и доступ пользователя.

     Каждому каталогу внутри DocumentRoot нужно назначить конкретные опции, управляющие индексированием, выполнением CGI и т.д. Обычно данные опции «прописывают» в основном файле конфигурации, но если он достаточно огромной и его неудобно править, разрешено применение файла .htaccess. Данный файл помещается непосредственно в тот каталог, опции которого нужно модифицировать. Предпочтительнее, конечно, хранить опции в основном файле конфигурации - так будет безопаснее.

Опции каталога помещаются в директиву <Directory>:

<Directory />

  Options FollowSymLinks

  AllowOverride None

</Direcroty>

     Данный пример взят из файла конфигурации Apache по умолчанию. Потому что опции наследуются для всех подкаталогов, то эти опции будут присвоены всем каталогам дерева DocumentRoot. Переопределить опции нужно с помощью директивы Directory - отдельно для каждого каталога.

     С точки зрения безопасности наиболее интересны следующие опции:

  • FollowSymLinks - следовать символическим ссылкам. Нужно выключить эту опцию, потому что она позволяет получить доступ к фалам, находящимся за пределами дерева DocumentRoot. К примеру, если Web-администратор специально создаст ссылку на файл /etc/passwd внутри дерева DocumentRoot, то при включенной опции FollowSymLinks кто угодно сможет просмотреть содержимое данного файла.
  • SymLinksIfOwnerMatch - следовать ссылке, если создатель ссылки представляется владельцем файла, на который указывает ссылка. Если необходимы символические ссылки, лучше использовать эту опцию вместо FollowSymLinks.
  • Indexes - если индексирование включено и файл index.html (или index.pl, index.php и пр.) не существует, то при запросе вида http://server/directory/ будет выведено содержимое каталога directory. Выключите опцию, чтобы никто не смог просмотреть содержимое каталога.
  • Includes - установка данной опции позволяет выполнение SSI (Server Side Includes) в данном каталоге. Наибольшая опасность SSI заключается в команде exec, позволяющей делать произвольные команды в системе, что недопустимо с точки зрения безопасности. Если обязательны SSI, рекомендуем включить следующую опцию.
  • IncludesNOEXEC — позволяет выполнять SSI, но запрещает команды exec и include.
  • ExecCGI - разрешает выполнение CGI-скриптов в данном каталоге. Если данная опция выключена, какой угодно CGI-сценарий может быть просмотрен как обычный HTML-документ. Если же опция включена, запрос CGI-скрипта приводит к его выполнению, а пользователь получает результат выполнения.

     Метод применения директив прежде кажется непонятным. Как было отмечено, все они наследуются, потому включение Indexes для /var/www/htdocs означает и включение данной директивы и для /var/www/htdocs/images (если, конечно, опции для каталога images не перезаписывают ее).

     Если в директиве Options указывать только одну опцию, это означает, что выключаются все другие опции, например:

Options FollowSymLinks

     Эта директива включает опцию FollowSymLinks и выключает все оставшиеся - Indexes, ExecCgi и др. Если можно выключить только одну опцию (к примеру, Includes), но оставить в покое все прочие, то перед опцией надо указать знак «-».

     Аналогично для включения явственной опции можно указать перед ней знак «+». Например:

Options -Includes

     Директива AllowOverride дает возможность указать, какие опции надо переопределять при употреблении файла .htaccess, а какие - нет. Но этим можно разрешить пользователю переопределить очень важные с точки зрения безопасности опции, поэтому лучше ее выключить:

AllowOverride none

     Надо установить список опций, которые могут быть переопределены:

AllowOverride ExecCGI Indexes Includes

     Рекомендуется запретить пользователям переопределение директив:

<Directory />

  Options None

  AllowOverride None

</Direcroty>

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена.

Если вы уже зарегистрированы как комментатор или хотите зарегистрироваться, укажите пароль и свой действующий email.
(При регистрации на указанный адрес придет письмо с кодом активации и ссылкой на ваш персональный аккаунт, где вы сможете изменить свои данные, включая адрес сайта, ник, описание, контакты и т.д.)



(обязательно)