Кто за экраном? Почему IP в логах может быть фальшивым

Прочитал, что в логах сайта могут быть адреса из диапазонов, которые в интернете не маршрутизируются — и это не сбой, а следствие неправильной настройки. Это меня насторожило, потому что в таких случаях система принимает ложные данные за реальные. И это не про «хакеров», а про то, как мы сами позволяем системе ошибаться.

О чём речь и почему я считаю это важным для сайта

Речь о заголовке X-Forwarded-For — он же «показывает, откуда пришёл пользователь». Но он же может быть подделан. И если сервер верит ему без проверки — он принимает ложные данные как реальные. Это не уязвимость в самом сайте, а в том, как он обрабатывает входные данные. И это касается всех, у кого есть прокси, балансировщик или CDN.

Считаю, что это важно, потому что в таких случаях система не может отличить настоящего пользователя от бота. А значит, защита, построенная на IP — ложная. И если вы не проверяете, откуда пришёл заголовок, вы уже утратили контроль над тем, кто может что-то делать на сайте. Это не про «взлом», а про то, как система может быть обманута без единой ошибки в коде.

Как это устроено — что тут вообще происходит

Когда запрос проходит через прокси, тот добавляет в заголовок X-Forwarded-For свой IP. А потом ещё один, и ещё. Итог — список, где каждый элемент — это адрес предыдущего узла. Самый правый — это адрес клиента, если он был добавлен вашим прокси. Но если вы не настроили доверие, то сервер может взять любой адрес из списка — даже из документационного диапазона, которого в интернете не существует.

А это значит, что кто угодно может прислать заголовок с любым IP — и система примет его за реальный. Особенно если в настройках стоит «берём первый элемент» или нет проверки. Это не ошибка в коде — это ошибка в логике. И она приводит к тому, что защита, основанная на IP, перестаёт работать.

Как понять, что это касается вашего сайта

Я проверяю это первым делом, когда вижу в логах аномалии: IP из диапазонов 198.51.100.0/24, 203.0.113.0/24, 10.0.0.0/8 — они не маршрутизируются в интернете. Это сигнал. Если в логах такие адреса — значит, кто-то подставляет заголовок. Или сервер его верит без проверки.

Проверяю, есть ли в конфигурации nginx директива real_ip_header X-Forwarded-For. Если есть — смотрю, задан ли set_real_ip_from. Если нет — значит, система верит всем. Если задан — проверяю, не слишком ли широкий диапазон. И если в логах видны расхождения между $remote_addr и $http_x_forwarded_for — это тоже сигнал. Это не ошибка, это предупреждение.

Что с этим делать

Что я делаю в таких случаях — начинаю с проверки настроек. Если в конфиге есть real_ip_header, но нет set_real_ip_from — добавляю. Если есть — уточняю, какие именно адреса доверяются. И не оставляю широкие подсети.

Проверяю, включён ли real_ip_recursive on — без этого система не может правильно определить адрес клиента. И проверяю, как в коде приложения берётся IP: везде ли используется один и тот же источник? Если нет — это риск. И если есть защита по IP — она должна работать от одного и того же значения. Иначе — можно обойти одну часть, не трогая другую.

Что здесь даёт поддержка

На постоянной поддержке я закрываю эту задачу так: проверяю конфигурацию, настраиваем доверие, включаю рекурсивный разбор, устанавливаю логирование обоих значений. И всё это — до того, как появится проблема.

Считаю, что почистить мало — надо закрыть причину, иначе вернётся. Заражают не «хакеры, выбравшие вас», а боты, массово сканирующие уязвимости. Если система принимает поддельные IP — они могут использовать это для обхода защиты.

Мониторинг доступности и ключевых страниц каждые несколько минут, 24/7. Это позволяет выявить аномалии до того, как они повлияют на работу сайта.

Приглашаю на бесплатный аудит безопасности — проверим, как обрабатывается входной трафик, и убедимся, что IP-адреса не подделываются.