Одним из рубежей защиты информации считается подсистема идентификации и аутентификации, которая обеспечивает безопасный доступ к ресурсам. Так как сегмент Интернета постоянно сканируется ботами, которые ищут уязвимые сервисы, то публичные решения находятся под постоянными Brute-Force атаками.
Где слабые механизмы, а где-то их отсутствие вовсе приводят к критическим последствиям и нанесению ущерба! В данном материале рассмотрим один из базовых способов аутентификации HTTP Basic Auth, его имплементацию и настройку пользователей.
Что такое HTTP Basic Auth?
Аутентификация бывает совершенно различной по типам проверки подлинности, когда используют: логины/пароли, подписанные токены, сертификаты, TOTP-коды, ключи шифрования и т.д. А так же по способу архитектурной реализации: модули, службы, внешние сервисы.
В нашем случае HTTP Basic Auth предоставляет базовую проверку по логину и паролю, будучи реализованным в виде модуля на веб/прокси решениях. Где аутентификационные данные передаются в заголовке и кодируются в Base64.
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= 
Обратите внимание, что передача подобного рода сенситивных данных должна происходить по защищенным протоколам! В данном случае, классически SSL позволит аутентифицировать сервер и сформировать зашифрованное соединение. Одним из недостатков такого рода аутентификации являются слабые пароли, которые перебираются утилитами, наподобие Medusa.
Как настроить аутентификацию?
Рассмотрим практический пример, того как настраивается такая проверка на nginx. Для начала перейдем к терминалу и установим все необходимые зависимости:
sudo apt update
sudo apt install nginx
Далее нам необходимо создать базу с пользователями, где пароли будут храниться в формате хеш-значений, для этого установим утилиту и выполним команды:
sudo apt install apache2-utils
Где каждый из элементов имеет свое значение: путь к будущей базе данных пользователей /etc/nginx/.htpasswd и имя создаваемого пользователя – mike.
sudo htpasswd -c /etc/nginx/.htpasswd mike 
Чтобы создать второго и последующих пользователей необходимо убрать опцию -c, которая создавала новый файл. После того, как пользователь в базе нужно перейти к изменению конфига. Найдем наш виртуальный хост:
nano /etc/nginx/sites-available/default По умолчанию, файл называется default, но в вашем случае он может быть другим! Добавим директиву, которая позволит перед подключением проводить проверку подлинности:
server {
listen 80;
server_name example.com;
location / {
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://localhost:8080;
}
} 
Проверку подлинности можно указать, как на конкретный путь веба, так и на весь виртуальный хост. Для этого поместите директивы auth_basic_user_file, auth_basic в блоки server или location. Проверьте конфиг перед запуском, если он корректен, то перезапустится служба:
sudo nginx -t && sudo systemctl reload nginx 
После чего можно перейти к адресу example.com и проверить работоспособность поднятого сервиса:
Отлично, при обращении на путь / срабатывает директива, которая и позволяет провести проверку относительно файла с пользователями и обработать дальнейшие пакеты, при подключении. Рекомендуется установить fail2ban, который сможет ограничить кол-во неудачных запросов и предотвратить НСД. В нашей базе знаний вы можете найти настройку и других способов аутентификации Digest, NTLM, Kerberos и прочие!
Для выполнения тестов, вы можете использовать изолированную среду VPS сервера, на любой из двух платформ vStack cloud или же VMware cloud. Нажмем на кнопку Создать сервер и выберем конфигурацию, подходящую под наши задачи, затем нажмем кнопку Создать.
Потребуется некоторое время для развертывания серверных мощностей. После чего вы можете подключиться любым из удобных способов.
