IP-фильтрация: whitelist, blacklist и real IP для nginx и Apache

IP whitelisting не работает: подменённые адреса и ложные блокировки

Обратный прокси или балансировщик перед веб-сервером ломает фильтрацию по ip — и это самая частая причина, по которой IP whitelisting ведёт себя непредсказуемо. Соединение до приложения устанавливает посредник, поэтому в правилах доступа вместо клиента оказывается адрес за прокси: один и тот же для всех посетителей — адрес шлюза или балансировщика.

Последствия симметричны и оба плохие. Белый список либо пропускает всех подряд, потому что каждый запрос приходит с одного «доверенного» адреса, либо отказывает каждому — если посредника в списке нет. Чёрный список жёстче: заблокировав один адрес, вы закрываете доступ целому пулу клиентов за этим балансировщиком, и ложная блокировка клиента превращается в отказ всей площадке.

Второй слой проблемы — доверие заголовкам. Клиент подставляет заголовок с адресом вручную, и если сервер принимает его без проверки, подменённый ip адрес обходит и белый, и чёрный список заодно. Правило здесь одно: заголовкам верим только от известных посредников и разбираем цепочку с конца — первый адрес принадлежит клиенту лишь тогда, когда все предыдущие входят в доверенные диапазоны сети.

Поэтому фильтрация по ip строится не на том, что видно в сокете, а на восстановленном адресе клиента. Дальше разбираем, как это закрывается: какие диапазоны объявить доверенными, в каком порядке читать цепочку при нескольких хопах и как проверить политику так, чтобы она не пускала лишних и не резала своих.

Что меняется после внедрения фильтрации на периметре

Пока фильтрация живёт только на балансировщике, реальный адрес клиента теряется: в журналах все запросы приходят с адреса самого прокси. Правила по источнику начинают работать вслепую — под отказ попадают легитимные пользователи за общим прокси, а нежелательный трафик проходит. Лечится это на уровне конфигурации: доверенные прокси перечисляются явно, заголовок с исходным адресом принимается только от них — в nginx это задаётся директивами модуля realip, в Apache — аналогичным механизмом.

После настройки считаем три величины, по которым видно, что изменилось на периметре.

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

Эффект держится, пока списки живые. Счётчики на отказы и на изменения списков дают алерт при всплеске, а раз в неделю состав пересматривается: устаревшие адреса подрядчиков уходят, временные доступы закрываются. Контроль источников трафика становится регламентом, а не разовой настройкой.

IP whitelisting: уровни фильтрации трафика и их ограничения

Правило фильтрации можно включать на нескольких уровнях: на сетевом экране или балансировщике, на обратном прокси, во внешнем фильтрующем слое и в самом приложении. Чем ближе правило стоит к источнику трафика, тем дешевле отсекается мусор, но тем меньше контекста доступно для решения: на нижних уровнях виден только адрес, а не домен, путь или учётная запись. Обратная сторона — правила на балансировщике не различают сервисы за одним адресом, поэтому для разных приложений часто нужен свой слой и свой список доверенных узлов.

Уровни не заменяют, а дополняют друг друга: сетевой отсекает явный мусор, прокси приводит адрес клиента к реальному, приложение принимает решение по ролям. Главное ограничение любой фильтрации — общий адрес: за одним узлом может стоять и офис целиком, и мобильный оператор, поэтому список доверенных узлов на сетевом уровне не разграничивает пользователей внутри. Эти ограничения принимают осознанно, а не обходят.

Порядок внедрения фильтрации: от аудита трафика до передачи

Порядок работ важнее инструмента: правило IP whitelisting, включённое до инвентаризации источников, отсекает живых партнёров и внутренние сервисы. Поэтому идём от карты трафика к конфигурации и на каждом шаге сверяем результат с реальными запросами, а не с предположениями.

1. Инвентаризация источников трафика. Собираем все точки входа: внешние интеграции, офисные и облачные адреса, служебные роботы, мониторинг. На выходе — список подсетей с пометкой «блокировать», «ограничить по частоте», «не трогать».

2. Схема прохождения трафика. Разбираем цепочку до приложения: где стоит балансировщик, сколько узлов проксируют запросы, из какого заголовка читается адрес клиента. Без этого фильтр видит адрес прокси и режет либо всех, либо никого.

3. Настройка правил доступа. Описываем белый и чёрный списки, отдельно закрываем административные разделы. Доверенные прокси настраиваются в связке с правилами — иначе исходный адрес подменяется первым же узлом на пути.

4. Прогон в режиме логирования. Правила включаем так, что запрещённые запросы пишутся в журнал, но пропускаются. За несколько суток видна вся картина ложных срабатываний — их вычищают до инцидента, а не после.

5. Проверка на боевом контуре. Рабочий режим включаем сначала на одном узле: сверяем долю отсечённых запросов и доступность сервисов. Откат — правка одного файла конфигурации и перезагрузка.

6. Передача в эксплуатацию. Отдаём схему, конфигурации, порядок добавления новых адресов и разбор типовых ошибок. Поддержка понимает, где менять список, а не ищет это по журналам в момент блокировки.

Что заказчик получает на руки: конфигурации, схемы и регламенты

Мы передаём работу не описанием «что сделали», а набором артефактов: их можно проверить, отдать другой команде и обновлять без нашего участия. Ниже — комплект, который остаётся у вас после внедрения IP whitelisting на nginx и Apache.

• Файлы конфигурации — готовые блоки для обоих серверов: правила allow/deny, доверенные прокси для восстановления реального адреса клиента, порядок применения директив и точки, куда вставлять новые записи. С комментариями к каждой строке, чтобы правку внёс дежурный, а не только автор схемы.
• Политика доступа — какие контуры закрыты фильтрацией, кого пускаем по умолчанию, что делаем с остальным трафиком и где заканчивается зона ответственности сети, а начинается приложения.
• Схема прохождения запросов — путь от клиента через балансировщик и прокси до приложения: на каком узле виден настоящий адрес, где он подменяется и как это проверить одной командой.
• Списки доверенных узлов — отдельно по каждому контуру, с владельцем записи, датой добавления и пометкой, можно ли её снимать.
• Инструкция для дежурной смены — сценарии на каждый случай: добавить адрес, снять блокировку, убедиться, что правило применилось, и что делать при ложном срабатывании вне рабочих часов.
• Регламент пересмотра правил — периодичность ревизии, кто подтверждает запись, как фиксируется причина исключения и когда адрес удаляется автоматически.

Комплект рассчитан на то, чтобы правила жили без автора: инженер смены может объяснить, почему конкретный адрес в списке и что будет, если его убрать.

Кейс: как убрали ложные блокировки клиентов за одну итерацию

До: правила блокировали не тех

Портал клиента стоял за балансировщиком и сетью доставки контента Cloudflare: на бэкенд все запросы приходили с адресов периметра, а не с адресов посетителей. Блокирующие правила срабатывали на адрес периметра, и под отсечение попадала целая ветка трафика доверенного клиента, а не источник аномалии. Пиковые часы стабильно давали 6–8% отказов доверенным клиентам, и каждый такой случай выглядел как «сайт работает, но не у меня».

Разбор инцидента упирался в журналы: в записях стоял один и тот же адрес, логи приходилось сопоставлять с выгрузкой из панели сети доставки, и поиск виновника занимал до 40 минут. Доля запросов с корректным исходным адресом не превышала 12% — статистика по фильтрации была непригодна для решений.

Что изменили и что стало

Восстановили исходный адрес на обоих фронтах: в nginx — модуль real_ip с явным списком доверенных подсетей и заголовком X-Forwarded-For, в Apache — модуль RemoteIP с доверенными прокси. Цепочку заголовков валидируем по длине и по доверию к источнику, иначе подставленный вручную X-Forwarded-For обошёл бы фильтр. Порядок правил перевернули в пользу белого списка: доверенные подсети и служебные адреса периметра проверяются раньше блокировок, а блокировки разнесены по классам — парсеры, сканеры уязвимостей, аномальная частота запросов.

В журнал теперь пишется исходный адрес, цепочка прокси и идентификатор клиента — инцидент разбирается по одной записи. Отказы доверенным клиентам прекратились, доля запросов с корректным адресом выросла до 100%, поиск виновника в журналах сократился с 40 минут до 2–3. Новые правила перед выкатом прогоняем на копии боевых логов в теневом режиме — регрессию видно до того, как её увидит клиент.

Чем фильтрация на балансировщике отличается от проверки в приложении

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

Проверка в приложении видит больше — токен, сессию, роль, идентификатор арендатора, путь и тело запроса. Зато платит полной стоимостью обработки: запрос уже принят, разобран, поднят контекст. Отсюда и порядок проверок: фильтр по адресу — на входе, пороги частоты — на балансировщике, решения по личности — уже в коде.

Главная ловушка — дублирование правил. Если один и тот же список адресов живёт и в конфигурации балансировщика, и в обработчике приложения, они разойдутся: правку внесут в одно место, второе останется с прошлой версией. Хуже, что отказ приходит без контекста — в логах приложения запроса просто нет, и разбор начинается с вопроса, был ли он вообще.

Отдельно про реальный адрес. За прокси клиентский адрес подменяется адресом посредника, и правило начинает пропускать или резать не того. Лечится это доверием к заголовку X-Forwarded-For только от известных промежуточных узлов и явным разбором цепочки — иначе адрес подделывается одним заголовком, и фильтр перестаёт что-либо значить.

Частые технические сомнения при настройке доступа

Вопросы, которые задают до старта, почти всегда касаются не синтаксиса правил, а поведения системы под нагрузкой и после изменений. Ниже — короткие ответы, которые снимают большую часть сомнений до начала работ.

Можем ли мы заблокировать живых клиентов?

Риск есть только при резком переходе в режим «запрещено всё, кроме списка». Поэтому сначала включаем запись без блокировки, собираем фактический трафик и по нему формируем белый список. Отключение — одной строкой конфигурации, без перезапуска сервиса.

У нас уже развёрнут прокси — схема меняется?

Меняется узел, на котором применяются правила: он должен быть первым, кто принимает соединение. Если фильтр поставить после посредника, он увидит один и тот же адрес для всех и либо заблокирует весь трафик, либо не заблокирует ничего.

Как часто пересматривать списки?

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

Как понять, что фильтр отсекает лишних?

Ведём счётчики отказов по каждому правилу и выводим их в мониторинг: рост доли отказов на конкретном пути — сигнал пересмотреть запись, а не ждать обращений. Ложные срабатывания разбираем по логам с адресом, путём и временем.

Обсудим вашу задачу фильтрации и вернёмся с планом работ

Чтобы фильтрация работала предсказуемо, начинаем со схемы прохождения трафика: где стоит балансировщик, на каком узле завершается шифрование и в какой точке теряется реальный адрес клиента. На этой картине сразу видно, какие заголовки доходят до nginx и Apache, где список разрешённых адресов сработает ложно, а где список запрещённых оставит обход.

Дальше определяем состав этапов внедрения и границы работ. План работ по доступам согласуем до правок конфигурации — с порядком выката, точками отката и ответственными на вашей стороне.

• Схема прохождения трафика с точками, где определяется реальный адрес клиента.
• Правила для nginx и Apache с приоритетами, исключениями и порядком применения.
• Настройка доверенных прокси и заголовков, чтобы реальный адрес нельзя было подменить извне.
• Регламент обновления списков доступа и порядок добавления новых адресов.
• Проверки на тестовом стенде и на боевом трафике, включая откат правил.
• Документация по конфигурации и передача вашей команде поддержки.

Опишите задачу фильтрации: что уже настроено, где стоят прокси и какие адреса нужно пускать или блокировать. Вернёмся с оценкой работ и планом, где по каждому этапу указаны сроки и результат.