Практический разбор · nginx
nginx realip: доверяйте X-Forwarded-For только своему proxy
ngx_http_realip_module может заменить адрес клиента значением из заголовка. Ограничьте set_real_ip_from только доверенными proxy, иначе клиент сможет подделать IP для логов и ACL.
Кому нужно проверить
Администраторам nginx за CDN, load balancer или ingress. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Модуль realip меняет client address на значение доверенного заголовка. Если set_real_ip_from включает недоверенную сеть или `0.0.0.0/0`, внешний клиент может передать ложный адрес. При real_ip_recursive nginx выбирает последний недоверенный адрес в цепочке, поэтому доверенные hops должны быть перечислены корректно.
Затронутые версии
Руководство относится к nginx со включённым ngx_http_realip_module и директивами set_real_ip_from/real_ip_header. Модуль не собирается по умолчанию; применимость зависит от реальной цепочки proxy и PROXY protocol.
Исправленные версии
Универсальной исправленной версии нет. Доверяйте только адресам известных proxy, выберите правильный заголовок или PROXY protocol и проверяйте цепочку до включения IP-based ACL или аудита.
Что сделать
- 1Нарисуйте фактическую цепочку client, CDN, load balancer и nginx. Определите, какой компонент формирует заголовок или PROXY protocol и какие адреса действительно доверены.
- 2Проверьте set_real_ip_from: замените широкие сети точными CIDR доверенных proxy и удалите правила для диапазонов, которые могут принимать пользовательский трафик.
- 3Сверьте real_ip_header с контрактом proxy и включайте real_ip_recursive только когда порядок доверенных hops понятен. Для PROXY protocol проверьте, что он включён и на listen, и на upstream transport.
- 4Сохраните исходные адреса через `$realip_remote_addr` в ограниченном диагностическом логе и не публикуйте внутренние адреса. Не используйте переписанный IP как единственную авторизацию.
- 5Проверьте конфигурацию на staging с разрешённым proxy и прямым недоверенным клиентом. Ожидаемый результат — заголовок от прямого клиента не меняет trusted address.
- 6После reload проверьте access logs, rate limiting и IP ACL, включая IPv6 и аварийный обход CDN. Сопоставьте наблюдаемые адреса с сетью доверенного proxy.
- 7Регулярно обновляйте список proxy при изменении провайдера и пересматривайте правила после миграции ingress или балансировщика.
Примеры конфигурации и проверки
nginx -T 2>/dev/null | grep -n -E 'set_real_ip_from|real_ip_header|real_ip_recursive'Read-only проверка активной конфигурации собственного nginx. Вывод может содержать внутреннюю топологию, поэтому не публикуйте его без редактирования. Команда не доказывает, что proxy действительно отправляет корректный заголовок и не меняет конфигурацию. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.