Безопасность Apache: управление доступом.
Метки: Apache | digest | htpasswd
Среда, 29 июля 2009 г.
Просмотров: 5214
Подписаться на комментарии по RSS
Ранее был рассмотрен HTTP-доступ со стороны клиента, теперь посмотрим на него с другой стороны - со стороны сервера.
Термины «авторизация» и «аутентификация» часто используются как взаимозаменяемые, но у каждого из них есть свое точное значение. Аутентификация - процесс проверки имени пользователя и пароля пользователя. А авторизация - это проверка полномочий пользователя: есть ли у данного пользователя права доступа к тому или иному объекту, к примеру файлу. Аутентификация часто (но не всегда) представляется первым шагом авторизации.
Целевыми объектами авторизации, конечно же, являются файлы и каталоги сервера: к примеру, надо создать каталог, доступ к которому разрешен только сотрудникам компании. В данном каталоге будут находиться некоторые важные внутренние документы или же программы, доступные только для сотрудников. В данном случае доступно два метода контроля доступа: проверка имени пользователя/пароля и проверка IP-адреса.
Начнем с доступа по IP-адресу.
Доступ по IP-адресу.
Данный способ позволяет установить IP-адреса отдельных машин или целых сетей, которым разрешен доступ к серверу. К примеру, для разрешения доступа к файлу private.html пользователей внутренней сети х.х.х.х (если Web-сервер нужен только для внутреннего употребления, нужно поместить его во внутреннюю сеть, а не в DMZ) может применяться следующий блок:
</Files>
Как было сказано ранее, можно задать как один-единственный адрес, так и целую сеть. Надо применять и имена узлов, но это снизит производительность, так как Apache будет претворять двойной DNS-запрос (начально он разрешит имя в IP-адрес, а затем полученный IP-адрес в имя, чтобы убедиться, что полученное имя совпадает с указанным).
Если же все-таки нужно указать имя узла, тогда рассмотрим следующий пример:
</Files>
Это совсем не то, что нужно: это правило будет совпадать с именами example.com, lan.example.com, sales.example.com, myexample.com и даже cracker.evilexapmle.com - то есть со всеми именами, которые содержат строку «example.com». Чтобы дать доступ только домену (и его поддоменам) 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>
Файл .htpasswd рекомендуется хранить за пределами каталога DocumentRoot сервера, к примеру, в каталоге /etc/httpd/.htpasswd. Конечно, современные версии Apache блокируют доступ к файлам .htpasswd, но лучше не рисковать. Современные версии Apache содержат директиву, ограничивающую доступ к файлам, начинающимся на .ht:
</Files>
Опции и доступ пользователя.
Каждому каталогу внутри DocumentRoot нужно назначить конкретные опции, управляющие индексированием, выполнением CGI и т.д. Обычно данные опции «прописывают» в основном файле конфигурации, но если он достаточно огромной и его неудобно править, разрешено применение файла .htaccess. Данный файл помещается непосредственно в тот каталог, опции которого нужно модифицировать. Предпочтительнее, конечно, хранить опции в основном файле конфигурации - так будет безопаснее.
Опции каталога помещаются в директиву <Directory>:
</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
Рекомендуется запретить пользователям переопределение директив:
</Direcroty>