Всех категорически приветствую!
Это предпоследняя заметка из цикла о базовой настройке web-сервера, и в ней разберем такие инструменты, как .htaсcess и .htpasswd.
Вариантов и целей использования этих инструментов множество, я разберу лишь следующие (которые нужны чаще всего мне, во всяком случае):
- ограничения доступа по IP-адресам (подсетям);
- редирект;
- авторизация на странице.
Что такое .htaccess и .htpasswd
.htaccess – это файл дополнительной конфигурации Apache, при помощи которого дифференцированно можно задавать дополнительные правила или точечно снимать глобальные ограничения; располагается в требуемой директории сайта; распространяет правила на все вложенные файлы и каталоги; путь к начальному каталогу задается в конфиге хоста;
.htpasswd – файл, говорящий сам за себя; хранит авторизационные данные, а именно логин (в открытом виде) и пароль (в виде хеша MD5); генерируется при помощи утилиты «htpasswd»; располагать его желательно в месте, закрытом от чужих глаз (например, где-нибудь в директории «/var/www/myhtpasswd/.htpasswd»).
.htaccess и .htpasswd – это просто общепринятые названия файлов. На самом деле, обозвать их можно как душе угодно (только придется немного подправить конфиг apache, что позволяет далеко не каждый хостинг, если вы пользуетесь услугами таковых). Точку в начале имени тоже желательно оставить – все-таки лучше, чтобы файлы с описанием параметров безопасности были скрытыми. Почему скрытыми? Ну, вы же не вывешиваете на стену пароли от своих соц.сетей, когда к вам приезжают гости… да и в ином случае вряд ли вывешиваете, потому что это просто тупо.
Настройка Apache и хостов для работы с .htaccess
Если вы решили использовать имя файла, отличное от .htaccess (например, .myhtrules), то нужно сходить в конфиг apache «/etc/apache2/apache2.conf» и поменять параметры:
- «AccessFileName .htaccess» на «AccessFileName .myhtrules»
- «<FilesMatch “^\.ht”>» на «<FilesMatch “^\.myht”>»
Первый параметр определяет имя файла с дополнительными правилами, а второй – запрещает показ всех файлов, имя которых начинается с «.myht».
После изменения конфига apache надо перезапустить:
#> systemctl restart apache2
Я имена файлов и конфигурацию не меняю, и далее буду работать с классическими .htaccess и .htpasswd.
***
Теперь поднастроим конфиг хоста.
Пусть у нас это будет первый хост с сайтом test-site1.ru (если непонятно откуда взялся test-site1.ru, то читайте статью о настройке виртуальных хостов).
Открываем конфиг хоста «/etc/apahce2/sites-available/tsite1ru.conf» (готовый конфиг взять можно ТУТ) и наблюдаем следующий раздел, отвечающий за работу с файлом .htaccess:
Используя директиву «Directory», задавайте путь относительно корня файловой системы сервака. Еще имеется директива «<Location>», которая задает путь относительно корня виртуального хоста (таковым в конфиге хоста является значение директивы «Document Root»)
В моем конфиге задан путь к корню виртуального хоста «/var/www/html/tsite1ru». Это говорит о том, что Apache будет искать файлик .htaccess начиная именно с корневого каталога хоста. Это нужно далеко не всегда, и путь можно указать, например, для какой-нибудь субдиректории (админки сайта).
Про директиву «Options» можно почитать ТУТ. Разжевывать не буду.
Директива «AllowOverride» имеет значение «All» - это значит, что Apache будет считывать все директивы из файла .htaccess. Если директива «AllowOverride» будет иметь значение «None», то директивы в .htaccess будет игнорироваться.
Эксперименты с .htaccess
Хотелось бы оговориться: под выражением «запретить/разрешить доступ к сайту, или к отдельным страницам сайта, или к отдельным файлам сайта» имеется ввиду «запретить/разрешить доступ к определенным директориям и файлам хоста (виртуального или физического – не важно)». Правила применяются именно к директориям и файлам, а не к какой-то хреновине, под названием «сайт».
Эксперимент первый. .htaccess в корне хоста (сайта)
Задачи:
1) разрешить доступ на сайт только с двух IP-адресов;
2) разрешить доступ на сайт с определенных подсетей;
3) запретить доступ на сайт только с двух IP-адресов;
4) запретить доступ на сайт только с определенных подсетей;
Формализуем первые две задачи: необходимо запретить доступ всем, кроме допущенных.
Формализуем вторые две задачи: догадались, думаю – разрешить доступ всем, кроме нежелательных.
Для реализации этих двух блоков задач имеются следующие наборы директив:
Для первой пары:
Order Deny,Allow
Deny from all
Allow from значение
Логика работы такая:
- серверу сказано, что правила нужно обработать в порядке сначала Deny (отказать), потом Allow (разрешить);
- следом идет правило «Deny from all», которое означает «отказать всем» и которое сервер, согласно установленному порядку, обработает первым; иными словами – «все, кто, пришел, сначала будут забанены»;
- затем идет правило перечисления допущенных «Allow from значение», которое сервер будет обрабатывать уже после правила «Deny»; по-русски - «из забаненных пустить только избранных».
Итак, в корне хоста (сайта) создадим файлик .htaccess:
#> touch /var/www/html/tsite1ru/.htaccess
И нашпигуем его таким содержимым:
order deny,allow
deny from all
allow from 192.168.44.103
allow from 192.168.44.130
allow from 10.44.17.0/24
Изменим права на файлик:
#> chown www-data:www-data /var/www/html/tsite1ru/.htaccess
#> chmod 440 /var/www/html/tsite1ru/.htaccess
(темы прав мы касались в статье про виртуальные хосты)
Почему доступ 440? Потому что не вижу смысла давать возможность www-data каким-либо образом изменять этот файлик или использовать как исполняемый, а другим и читать его ни к чему.
Таким образом, мы разрешили доступ только с IP 192.168.44.103, 192.168.44.130 и из подсети 10.44.17.0/24.
Если мы теперь постучимся на сайт с любого из этих адресов или с адреса, принадлежащего диапазону подсети 10.44.17.0/24, то все загрузится как обычно, но стоит нам попробовать зайти, например, с IP 192.168.44.105 или 10.44.18.100, то сервер будет не очень-то и любезен:
Перезагружать Apache после создания/изменения/удаления файлика .htaccess не нужно!
***
Первые две задачи победили. Что касается вторых двух, то тут, просто-напросто, Allow и Deny меняются местами.
Поскольку теперь стоит задача разрешить доступ всем, кроме нежелательных, то .htaccess будет выглядеть так:
order allow,deny
allow from all
deny from 192.168.44.103
deny from 192.168.44.130
deny from 10.44.17.0/24
Теперь доступ к сайту организован с точностью, да наоборот: попасть на сайт можно откуда угодно, кроме указанных IP-адресов и диапазона 10.44.17.0/24.
Эксперимент второй. .htaccess в корне хоста (сайта) и в субдиректории «/adminka»
Задачи:
1) Запретить заходить на сайт с диапазона 192.168.44.0/24;
2) Разрешить заходить в админку сайта с IP-адреса 192.168.44.100 (принадлежит подсети 192.168.44.0/24, для тех, кто не знает).
Для выполнения первой задачи приведем наш .htaccess, лежащий в корне сайта, к такому виду:
order allow,deny
allow from all
deny from 192.168.44.0/24
Для выполнения второй задачи, создадим в корне хоста (сайта) субдиректорию «adminka» и сразу назначим ей права:
#> mkdir /var/www/html/tsite1ru/adminka
#> chown www-data:www-data /var/www/html/tsite1ru/adminka
#> chmod 755 /var/www/html/tsite1ru/adminka
Скопируем в эту субдиректорию файлики index.html и .htaccess из корня сайта:
#> cp /var/www/html/tsite1ru/.htaccess /var/www/html/tsite1ru/adminka
#> cp /var/www/html/tsite1ru/index.html /var/www/html/tsite1ru/adminka
Подкрутим файлик .htaccess в «админке» до такого состояния:
order deny,allow
deny from all
allow from 192.168.44.100
И в этой же «админке» подкрутим файлик index.html: к «Site 1» добавим слово «Adminka»:
Теперь, если мы будем пытаться зайти на главную страницу сайта с IP 192.168.44.100, сервак нас завернет:
Но если мы попробуем войти в админку «test-site1.ru/adminka», то:
В админку мы успешно попадаем.
Выводы.
Используя .htaccess, можно точечно прописывать правила для нужных директорий (разделов сайта). Правила .htaccess, стоящего в иерархии выше текущего, на данную директорию (и на все, что в ней) уже не распространяются – тут работает свой .htaccess. И так ступенчато можно использовать .htaccess хоть для каждой директории и ее субдиректорий, задавая везде свои правила.
Эксперимент третий (на основе второго). Изменяем директорию в конфиге хоста
В самом начале статьи мы настраивали конфиг хоста для работы с .htaccess и в директиве «<Directory>» прописывали путь к папке, начиная с которой будут работать правила .htaccess:
Поменяем путь. Пропишем теперь сюда «админку»:
Перезагрузим конфиги Apache:
#> systemctl reload apache2
И попробуем зайти на сайт (с IP 192.168.44.100):
Теперь, несмотря на наличие .htaccess с запретом в корне сайта, сервак нас не заворачивает, потому что файлики .htaccess будут подключаться, начиная с директории «/adminka».
***
Если .htaccess так же нужно применить к директории, не вложенной в директорию «/adminka» (например, к соседней директории «images» в корне сайта), то в конфиг хоста нужно добавить еще одну директиву «<Directory>» с указанием соответствующего пути:
Перезагрузить конфиги Apache и организовать в директории «/images» файлик .htaccess с нужными параметрами. Например, я запрещу доступ к директории «/images» с IP 192.168.44.100:
Редирект в .htaccess
В прошлой статье мы делали редирект с http на https при помощи конфига хоста.
Теперь потренируемся перенаправлять запросы при помощи .htaccess.
Вариантов множество, все приводить не буду, покажу лишь рабочий пример наиболее популярного редиректа – перенаправить абсолютно все запросы с http на https.
Тренируемся на файлике .htaccess, лежащим в корне хоста (сайта) test-site1.ru. Для этого не забудьте вернуть в конфиге хоста обработку .htaccess начиная с корневой директории и перезагрузить конфиги apache.
Для начала включим в Apache модуль «rewrite» и рестартанем его:
#> a2enmod rewrite
#> systemctl restart apache2
Теперь в .htaccess организуем редирект на https абсолютно всех запросов, приходящих на хост:
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
Сохраняем файлик и пробуем зайти на test-site1.ru по http.
Различные вариации редиректов и их реализацию можно поглядеть ТУТ и ТУТ.
Авторизация и .htpasswd
Возникают ситуации, когда страницу сайта (доступ в файлам и папкам хоста) нужно запаролить, а изобретать механизм авторизации, использующий БД и горстку php-сценариев, долго и нет смысла.
В таких случаях хорошо выручает апачевский htpasswd.
Утилита «htpasswd» входит в состав пакета «apache2-utils». Если у вас такой не установлен (при попытке выполнить команду htpasswd вывалится ошибка - :Command not found…:), то ставим:
#> apt install apache2-utils
Данная утилита создает файлик (классически это .htpasswd), который хранит открытое имя пользователя и MD5 хеш пароля.
Как я и говорил ранее, хранить .htpasswd лучше в стороне от чужих глаз, например, в домашней директории вашего подрутового админа. Я храню .htpasswd в директории «/var/www/myhtpasswd».
Итак, создадим директорию хранения файлика .htpasswd и зададим права:
#> mkdir /var/www/myhtpasswd
#> chmod 766 /var/www/myhtpasswd
Теперь сгенерим файлик .htpasswd
#> htpasswd –c /var/www/myhtpasswd/.htpasswd user1
Вводим пароль для user1 и подтверждаем его.
Теперь сразу же добавим второго пользователя (из команды убирается параметр «-с»):
#> htpasswd /var/www/myhtpasswd/.htpasswd user2
Меняем права на созданный файлик^
#> chown –R www-data:www-data /var/www/
#> chmod 644 /var/www/myhtpasswd/.htpasswd
если будет косяк с правами доступа пользователя apache к файлу .htpasswd, то обязательно получите ошибку сервера «500 : Internal Server Error»:
Глянем его содержимое для интереса:
Вроде все на месте. Осталось прикрутить данный механизм к сайту (хосту).
Попробуем запаролить нашу «админку». Для этого нам нужен её .htaccess («/var/www/html/tsite1ru/adminka/.htaccess»). Затолкаем в него следующее содержимое:
AuthType Basic
AuthName “Please authenticate!”
AuthUserFile /var/www/myhtpasswd/.htpasswd
Require valid-user
(про назначение этих директив можно почитать ТУТ)
Теперь пробуем попасть в админку:
Вводим User2, к примеру, и пароль от него:
Что и требовалось получить.
На этом сегодня все!
Почитать про дополнительный функционал .htaccess можно на хабре
Почитать про варианты использования .htpasswd можно ТУТ или ТУТ.
Шпаргалка:
Создать файл .htpasswd: htpasswd –c /путь/.htpasswd user1
Добавить пользователя в существующий файл .htpasswd: htpasswd –c /путь/.htpasswd user2
В следующей статье завершаем базовую настройку web-сервера и настроим утилиту защиты от брутфорса – fail2ban.
Ставьте лайк и подписывайтесь!
До связи!
