Заказчик — сервис с заметным публичным трафиком, размещённый за Reverse Proxy (Cloudflare/аналогичным CDN-решением). По понятным причинам NDA название, домен и контактные данные клиента в публичной версии кейса не раскрываются. Внутренней серверной экспертизы у заказчика нет, технические работы по инфраструктуре ведёт внешний подрядчик. В рамках этого контракта все работы по диагностике, перенастройке сервера и настройке Fail2Ban я выполнил лично — от первичного анализа логов до финальной передачи документации клиенту.
Согласование передачи данных о реальных IP-адресах посетителей со стороны инфраструктуры заказчика проводилось напрямую с техническим специалистом клиента. Я базируюсь в Москве и работаю с заказчиками из любого региона РФ, СНГ и за рубежом — в данном случае все работы были выполнены удалённо, без выезда на площадку.
Проблема
Заказчик обратился с жалобой на регулярные массовые бот-атаки, создающие заметную нагрузку на сервер и засоряющие статистику посещений. При первичном анализе access-логов Nginx выяснилась фундаментальная проблема: из-за использования Reverse Proxy в логах фиксировались только IP-адреса прокси-сервера, а не реальные IP-адреса конечных пользователей и ботов. Это означало, что любая попытка настроить защиту по IP-адресам, rate-limiting или Fail2Ban была технически бессмысленной — система видела бы «одного пользователя» (прокси-сервер), под маской которого скрывались тысячи реальных соединений.
Без корректного логирования реальных IP невозможно ни идентифицировать источник атаки, ни отличить вредоносный трафик от легитимного, ни обоснованно применять правила блокировки. Любая автоматическая защита в таких условиях работает «вслепую» и рискует либо заблокировать реальных пользователей, либо пропустить атаку. Поэтому первым и обязательным шагом было восстановление прозрачности трафика на уровне access-логов.
Решение
Работа была организована в шесть последовательных этапов, каждый из которых я выполнял лично. Подход — максимально осторожный: приоритетом было не «закрыть атаки любой ценой», а обеспечить корректную работу сервиса для легитимных пользователей, не разрушив существующую интеграцию с Reverse Proxy.
Этап 1. Анализ логов сервера
- Сбор access- и error-логов Nginx за репрезентативный период (7 дней).
- Анализ структуры логов и выявление аномалий: один и тот же IP-адрес прокси-сервера фигурировал в 99%+ записей, что делало невозможным анализ поведения реальных пользователей.
- Сопоставление объёма трафика с показаниями мониторинга Reverse Proxy — расхождение подтвердило, что значительная часть IP-адресов «схлопывается» на уровне прокси.
Этап 2. Согласование передачи реальных IP
- Коммуникация с техническим специалистом заказчика для организации передачи заголовков с реальными IP-адресами от Reverse Proxy к серверу.
- Согласование формата заголовков (X-Forwarded-For, X-Real-IP) и проверка их фактической передачи на стороне Reverse Proxy.
- Фиксация договорённостей в техническом документе, чтобы в будущем при смене конфигурации прокси формат передачи IP не «потерялся».
Этап 3. Перенастройка сервера для корректного логирования
- Настройка Nginx на обработку заголовков X-Forwarded-For / X-Real-IP с проверкой доверенной подсети прокси-сервера (иначе возникает риск подмены IP).
- Включение real_ip_header и set_real_ip_from для корректной подмены адреса в логах.
- Изменение формата access-лога для сохранения как реального IP пользователя, так и исходного адреса прокси (на случай отладки).
- Проверка: после перенастройки в логах начали отображаться реальные IP-адреса посетителей и ботов, что обеспечило прозрачность трафика для дальнейшего анализа и фильтрации.
Этап 4. Установка и настройка Fail2Ban
- Установка Fail2Ban на сервер с интеграцией с Nginx access-логами.
- Конфигурация кастомных jail под выявленные паттерны атак: brute-force на авторизацию, сканирование уязвимых URL, аномально высокая частота запросов с одного IP.
- Настройка параметров findtime, maxretry и bantime под реальные паттерны трафика клиента — чтобы блокировка срабатывала на бот-атаку, но не на легитимного пользователя, временно проявляющего активность.
- Подключение мониторинга Fail2Ban: алерты при всплеске количества заблокированных IP, что служит ранним индикатором массированной атаки.
Этап 5. Мягкие правила защиты от бот-атак
- Разработка поведенческих правил: блокировка по signature-паттернам User-Agent, типичным для сканеров; rate-limit на чувствительные эндпоинты (авторизация, формы, API).
- Создание whitelist для известных легитимных ботов (Googlebot, YandexBot, Bingbot) с проверкой по reverse DNS — чтобы не заблокировать поисковых роботов, от которых зависит SEO.
- Постепенный запуск правил в режиме log-only (без блокировки) для сбора статистики и калибровки порогов, затем переход в режим enforce.
Этап 6. Отказ от жёсткой гео-блокировки
- Рассмотрена и сознательно отклонена опция блокировки трафика по странам.
- Причина: значительная часть легитимных пользователей клиента использует VPN и прокси-серверы (включая корпоративные), поэтому жёсткие гео-правила привели бы к необоснованной блокировке реальных посетителей и ухудшению доступности сервиса.
- Вместо этого выбран поведенческий подход: блокировка по активности и signature-паттернам, который корректно работает с пользователями за VPN.
Результаты
Все работы выполнены в течение одного рабочего дня. Система логирования теперь корректно фиксирует реальные IP-адреса пользователей и ботов, что обеспечило прозрачность трафика и пригодность access-логов для дальнейшего анализа и настройки защиты. Реализована гибкая защита от бот-атак с минимизацией риска блокировки легитимных пользователей — за 6+ месяцев наблюдения не зафиксировано ни одной жалобы на ложную блокировку со стороны реальных посетителей.
| Показатель | Результат |
| Время на диагностику и полную реализацию | 7 рабочих дней |
| Источник проблемы | Reverse Proxy скрывал реальные IP в access-логах |
| Установлено средство защиты | Fail2Ban + кастомные jail |
| Тип правил защиты | мягкие (поведенческие), без жёсткой гео-блокировки |
| Видимость трафика в логах | 100% реальных IP пользователей и ботов |
| Массовых атак в сутки (отражается) | до 10 |
| Ложных блокировок легитимных пользователей | 0 за 6+ месяцев |
| Нагрузка на сервер от ботов | снижена до фоновых значений |
После запуска Fail2Ban и мягких правил в логах стала отчётливо видна картина атак: ежедневно отражается до 10 массовых бот-атак, создающих нагрузку на сервер и ранее засорявших статистику. Теперь эти атаки автоматически блокируются на уровне Fail2Ban, не доходя до приложения, а сервер работает в штатном режиме даже в пиковые моменты. Дополнительно клиент получил понятную отчётность по типам атак и источникам, что позволяет принимать обоснованные решения по дальнейшему усилению защиты.
Технологический стек
Nginx
Reverse Proxy (Cloudflare-совместимый)
X-Forwarded-For / X-Real-IP
Fail2Ban
IPTables / nftables
Custom jail rules
Rate limiting
Reverse DNS verification
Bot signature filtering
Log analytics