Практический разбор · nginx
nginx Basic Auth: защитите служебный endpoint без слабого hash
HTTP Basic Authentication ограничивает доступ к ресурсу парой имени и пароля, но не шифрует transport. Используйте её только поверх TLS, храните htpasswd с сильным hash и дополнительно ограничивайте служебные маршруты по сети.
Кому нужно проверить
Администраторам nginx, которым нужно временно или постоянно ограничить служебные страницы, мониторинг и тестовые панели. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Basic Auth передаёт credentials в каждом запросе в закодированном, но не зашифрованном виде. nginx предупреждает не использовать plain и unsalted SHA-1 для новых паролей; файл с credentials также должен быть недоступен web-клиенту. Парольная защита не устраняет риск CSRF, утечки через логи и компрометации доверенного proxy.
Затронутые версии
Руководство относится к nginx с ngx_http_auth_basic_module и директивами auth_basic/auth_basic_user_file. Точная поддержка схем hash зависит от версии nginx и формата файла; модуль сам по себе не заменяет TLS, MFA или контроль сети.
Исправленные версии
Универсальной исправленной версии нет. Отключите Basic Auth для ненужных locations, включайте её только поверх HTTPS, используйте поддерживаемую схему hash и ограничьте endpoint через allow/deny, VPN или отдельный identity proxy.
Что сделать
- 1Составьте список locations, где нужна парольная защита, и удалите Basic Auth с публичных статических ресурсов и маршрутов, которым она не нужна. Определите владельца учётных записей и срок их действия.
- 2Проверьте, что весь путь до клиента использует HTTPS и корректный сертификат. Не считайте внутренний HTTP между proxy и nginx безопасным без оценки сети и доверия к proxy.
- 3Создайте отдельный файл credentials вне web root с поддерживаемым сильным hash через штатный htpasswd и ограничьте права чтения пользователем nginx. Не храните реальные пароли в репозитории или shell history.
- 4Сочетайте auth_basic с allow/deny, VPN или identity-aware proxy для служебных endpoint. Не разрешайте широкий диапазон адресов только ради удобства диагностики.
- 5Проверьте конфигурацию и поведение на staging: без credentials должен быть отказ, с корректной учётной записью — только разрешённый ресурс, а credentials не должны появляться в access/error logs.
- 6Примените reload штатной процедурой и повторите проверку через каждый внешний proxy и IPv6 endpoint. Сохраните предыдущую конфигурацию для быстрого безопасного отката.
- 7Регулярно ротируйте пароли, удаляйте неиспользуемые учётные записи и пересматривайте, не заменяет ли Basic Auth более подходящий SSO/MFA механизм.
Примеры конфигурации и проверки
nginx -T 2>/dev/null | grep -n -E 'auth_basic(_user_file)?|satisfy'Read-only проверка активной конфигурации собственного nginx. Вывод может содержать пути и внутренние locations, поэтому не публикуйте его без редактирования. Команда не проверяет TLS, права файла и реальную доступность через proxy. Не передавайте пароль в командной строке. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.