HTTP-Аутентификация и дополнительная защита сайта

Как обеспечить дополнительную защиту административного и других важных разделов сайта независимо от системы управления сайтом средствами веб-сервера Apache?

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

Сегодня рассмотрим универсальный способ дополнительной защиты, а именно HTTP авторизация на уровне сервера.

По данным авторитетного ресурса netcraft.com HTTP-сервер Apache обслуживал порядка 160 млн сайтов в мире (59%) в 2011 году и по настоящее время является лидером в этой области. Соответственно, средства безопасности именно этого ПО будем сегодня рассматривать.Основными являются:

• Ограничение доступа к определённым директориям или файлам;
• Авторизация пользователей на основе HTTP-аутентификации (mod_auth_basic) и digest-аутентификации (mod_auth_digest);
• Ограничение доступа по IP-адресам пользователей;
• Запрет доступа к определённым типам файлов.

С ограничением доступа к директориям и файлам все понятно. У них есть определенные права на запись, чтение и исполнение для владельца, группы и остальных пользователей.

HTTP-аутентификация

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

login.php

, а также папка

admin

, которые нам нужно защитить. Для этого потребуется внести правки в

.htaccess

файл. Если этого файла нет в корне сайта, или в папке «admin», то его нужно будет создать, но в большинстве случаев он присутствует, и содержит в себе уникальные настройки для сайта, начиная от кодировки и заканчивая правилами перенаправлений и ЧПУ.

AuthName "Authentication"
AuthType Basic
AuthUserFile /home/root/www/website.com/.htpasswd
require valid-user

Выше представлен код, который реализует HTTP-аутентификацию. Находится он в той директории, которую мы хотим защитить и прописан в файле

.htaccess

.

Разберем его по строкам:

1. В кавычках находится сообщение, которое будет указывать пользователю необходимость авторизоваться для доступа к данной директории;
2. Тип аутентификации. Всегда ставьте Basic, он без проблем поддерживается всеми браузерами и везде работает корректно;
3. Путь к файлу, в котором находятся данные о пользователях и паролях, мы создадим его следующим этапом;
4. Строка, которая указывает, что доступ к данным получит только valid-user, т. е. только тот, кто авторизуется.

Для того, чтобы защитить файл

login.php

, который находится в корне нашего сайта, в корневом .htaccess пропишем следующий код:

<Files login.php>
AuthName "Authentication"
AuthType Basic
AuthUserFile /home/root/www/website.com/.htpasswd
require valid-user
</Files>

Тот же самый код, обрамленный в условие, которое касается только файла

login.php

. Все очень просто и понятно.

Приступим к созданию файла

.htpasswd

. Он создается утилитой, которая входит в ПО Apache. Можно скачать и отдельно, работает она из командной строки, без GUI.

htpasswd -cm .htpasswd admin

Подробнее о команде:

• 
с

  – ключ create создает новый файл;
• 
m

  – шифрует пароли по алгоритму MD5;
• 
.htpasswd

  – имя файла с паролями;
• 
admin

  – пользователь, пароль которого будет добавлен.

Результатом выполнения этой команды в консольной строке вам предложат ввести пароль и подтвердить его. В случае совпадения введенных данных появится новый файл, который необходимо будет расположить по адресу, указанному в

.htaccess

(в нашем примере это

/home/root/www/website.com/

). Обратите внимание, путь должен быть полным, узнать его можно в

phpinfo()

.

Ограничение доступа по IP-адресам

Ну и рассмотрим простой пример, как организовать политику доступа через ip-адреса. Для этого я просто приведу два простых примера.

Первый случай наиболее распространенный и часто встречается, смысл его в фразе «Запрещаем всем, кроме меня»:

Order Deny,Allow       # Порядок, сначала Запрещаем, потом Разрешаем
Deny from all          # Запрещаем всем!
Allow from 192.168.1.1 # Разрешаем, если ip-пользователя соответствует 
Allow from 192.168.1.2 # Разрешаем, если ip-пользователя соответствует

Первый случай менее распространенный но порой и такое может пригодиться, особенно если знаешь, откуда может прийти беда. Смысл во фразе «Можно всем, кроне него!»:

Order Allow,Deny       # Порядок, сначала Разрешаем, потом Запрещаем
Allow from all         # Разрешаем всем!
Deny from 192.168.1.1  # Запрещаем, если ip-пользователя соответствует 
Deny from 192.168.1.2  # Запрещаем, если ip-пользователя соответствует

Данный способ очень хорош для тех, кто обладает «белым» IP-адресом. В то же время, для «серых» и динамических адресов тоже есть вариант. Можно в эти правила добавлять целые подсети. Конечно, админка будет доступна еще определенному кругу лиц, но их круг сузится со всего мира до одного района.

P. S.: Неприятные сюрпризы

Случилось так, что занимаясь собственно как раз этой самой HTTP-аутентификацией, я наткнулся на то, что браузеры не открывали приватную страницу, ссылаясь на

бесконечную циклическую переадресацию

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

401.shtml

. Она отображается в случае провала, т.е. неправильного ввода комбинации логин-пароль.

---