Практический разбор · nginx
nginx stub_status: не публикуйте служебную статистику
Модуль nginx stub_status показывает активные соединения, принятые запросы и состояния workers. Ограничьте endpoint доверенной сетью или локальным доступом и не считайте небольшую страницу безопасной для публикации в интернет.
Кому нужно проверить
Администраторам nginx и командам мониторинга. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
stub_status отдаёт active connections, accepts, handled, requests, Reading, Writing и Waiting. Эти значения не содержат тело запроса, но помогают оценить нагрузку, время и поведение сервера. Если endpoint открыт всем, он становится дополнительной точкой разведки и расходует ресурсы на каждый запрос.
Затронутые версии
Руководство относится к nginx с включённым ngx_http_stub_status_module и location, где задана директива stub_status. Модуль не собирается по умолчанию; точная конфигурация зависит от сборки и reverse proxy.
Исправленные версии
Универсальной исправленной версии нет. Удалите ненужный endpoint либо ограничьте его через allow/deny, отдельный auth layer и сетевую политику; публикуйте только минимально необходимые метрики.
Что сделать
- 1Найдите location с `stub_status` в активной конфигурации и определите, кто должен читать метрики. Учитывайте include-файлы и конфигурацию ingress/reverse proxy.
- 2Если метрики не нужны, удалите location из источника конфигурации и запланируйте reload с проверкой синтаксиса. Не редактируйте только сгенерированный файл.
- 3Если endpoint нужен, ограничьте его allow доверенными CIDR или unix socket и добавьте отдельную аутентификацию/сетевой контроль. Правила nginx проверяются последовательно до первого совпадения.
- 4Проверьте, что внешний proxy не раскрывает endpoint через другой hostname, IPv6 или альтернативный путь. Не используйте широкое `allow all` рядом с чувствительной статистикой.
- 5Сначала проверьте конфигурацию на staging и убедитесь, что система мониторинга получает нужный ответ, а публичная точка получает отказ.
- 6Примените reload штатным способом и повторно проверьте endpoint с разрешённой и запрещённой сети. Наблюдайте ошибки и нагрузку после изменения.
- 7Регулярно ищите служебные locations при ревью конфигурации и не включайте их в публичные health routes без явной необходимости.
Примеры конфигурации и проверки
nginx -T 2>/dev/null | grep -n -C 2 'stub_status'Запускайте на собственном nginx с правом читать активную конфигурацию; команда ничего не меняет. Вывод может содержать внутренние адреса, имена upstream и секретные заголовки, поэтому не публикуйте его целиком. Отсутствие совпадения не исключает endpoint в конфигурации другого proxy или ingress. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.