Для большинства компаний защита от DDoS‑атак на уровне приложений стала базовым принципом построения безопасности бизнеса. Традиционно для этой цели используется схема с reverse proxy: трафик перенаправляется на провайдера защиты путем изменения DNS‑записей. Этот подход универсален, но имеет ряд существенных ограничений, которые могут стать критическими, когда требуется оперативно защитить множество сайтов. В статье рассмотрим два способа фильтрации трафика для защиты от DDoS-атак и разберемся, для каких задач каждый из них подходит.

Специфика Reverse Proxy

Основная проблема — зависимость от управления DNS-записями. Чтобы пустить трафик через защитного провайдера, нужно менять DNS для каждого домена и поддомена.

Когда у проекта десятки доменов — это неудобно. Когда их тысячи — это превращается в нескончаемую рутину, где любая ошибка ударит по доступности сервиса.

Кроме того, включение защиты через Reverse Proxy не закрывает уязвимость на уровне прямого IP. Если атакующий знает реальный адрес сервера, он может направить трафик напрямую, обходя защитный узел. В итоге формально защита есть, а фактически — нет.

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

Отсутствие контроля над DNS

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

Прозрачность защищенного IP

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

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

Неэффективность против целевых атак на IP

Смена A‑записи не защищает от атак, направленных непосредственно на реальный IP клиента. Злоумышленник может выявить целевой IP, направить трафик напрямую на этот адрес, перегрузить канал, даже если фаервол отбрасывает пакеты (трафик все равно идет по физическому каналу провайдера и занимает пропускную способность). В ситуации, когда у клиента полоса пропускания в 1 Gbps, а атакующий трафик — 2 Gbps, легитимный уже будет вытеснен, даже если сервер игнорирует вредоносные пакеты.

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

Рассмотрим процесс с применением блэкхола на схеме ниже пошагово:

1. Исходное состояние до защиты

Сервис доступен по старому IP 185.122.1.1, который знают клиенты.

2. Начинается DDoS-атака

Слева (INET) идет мощный поток трафика (на схеме «100 Гб») в сторону хостинга/провайдера. Этот поток направлен на новый целевой IP 175.144.3.3 (на схеме — NEW целевой IP). То есть атакующий или часть сети генерирует большой объем трафика на целевой адрес, который сейчас назначен у провайдера.

3. Реакция провайдера — часть трафика уходит в блэкхол

Стрелка от провайдера к блэкхолу с подписью 185.122.1.1 (старый целевой IP). Здесь видно, что для старого IP (или для части трафика) применяется метод защиты «черная дыра» — трафик на этот адрес заблокирован/отбрасывается, чтобы не перегружать инфраструктуру.

Иными словами: провайдер/оператор может перенаправлять атакующий трафик в блэкхол по выбранному маршруту.

Именно из-за необходимости ручного управления тысячами DNS-записей и риска обхода защиты по прямому IP (уязвимость к целевым атакам) возникает проблема: чем масштабнее проект, тем острее ощущается потребность в немедленной защите, но тем рискованнее и медленнее становится ее оперативное внедрение или изменение через классический Reverse Proxy.

Далее рассмотрим технологию, которая предлагает принципиально иной подход — защиту веб-приложений без смены А-записей.

Проксирование без смены А-записей DDoS-Guard

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

• IP‑адрес ресурса остается неизменным (видимым как клиентский);
• весь путь трафика проходит через фильтры провайдера;
• переключение защиты выполняется мгновенно через интерфейс управления.

Благодаря проксированию без смены А-записей можно гибко управлять обработкой веб-трафика не только отдельных сайтов, но и целых сетей.

Как работает технология

1. Прежде чем попасть в сеть клиента, трафик из интернета проходит анализ и очистку от мусора на фильтрующих устройствах сетевого и транспортного уровня модели OSI.
2. После этого на уровне приложений обрабатывается TCP‑трафик, который относится к IP‑адресам с активированной функцией перехвата (как в режиме полного, так и выборочного контроля) и адресованный на стандартные порты — 80 и 443. Далее трафик перенаправляется на аналитические устройства — прокси‑серверы, которые выполняют его дальнейшую фильтрацию и обработку.
3. Если перехват трафика невозможен, он направляется на целевой IP‑адрес без каких‑либо изменений и без использования прокси.

Для проектов с 1 тыс. и более поддоменов такое решение является оптимальным. Оно устраняет необходимость вручную управлять тысячей DNS‑записей — выполнить это без рисков и ошибок практически невозможно. Кроме того, решение существенно упрощает автоматизацию: одно действие (анонс или снятие префикса) заменяет тысячу изменений в DNS.

Ключевые преимущества

Ключевое преимущество — моментальное переключение трафика без задержек, обусловленных DNS механизмами (нет зависимости от DNS TTL: даже при TTL = 86400 сек (24 часа) трафик перенаправляется мгновенно).

Основа механизма: BGP-анонсы. Подключение трафика реализуется через анонсирование IP-префиксов по протоколу BGP на стороне провайдера защиты. Схема работы следующая:

1. Провайдер устанавливает BGP‑сессию с клиентом.
2. В штатном режиме, если не требуется L7 защита — неактивен и перехват трафика, если же требуется срочное включение — клиенту достаточно зайти в ЛК и активировать его в один клик.
3. При активации защиты провайдер отправляет BGP‑анонс для защищаемых префиксов, указывая себя в качестве следующего узла маршрутизации данных.
4. После получения BGP-анонса обновляются таблицы маршрутизации.
5. Трафик, адресованный к защищаемым префиксам, начинает маршрутизироваться через узел провайдера защиты.
6. Переключение происходит на уровне IP‑маршрутизации, минуя DNS‑инфраструктуру.

Практические сценарии применения защиты без смены A-записей DDoS-Guard

Для компаний с распределенной инфраструктурой по всему миру, но с единым центром управления (например, медиа-холдинги или стриминговые сервисы)

• Полный перехват трафика для всей сети.
• Выборочная защита критичных сервисов (CRM, ERP).
• Централизованное управление без изменения DNS в филиалах.

Для хостинг‑провайдеров и дата‑центров

• Выборочный перехват трафика по доменам (через SNI для HTTPS).
• Индивидуальная настройка правил для каждого клиента.
• Сохранение A‑записей клиентов.

Для e‑commerce с микросервисной архитектурой

• Полный перехват для публичных API (80/443 порты).
• Приоритетная защита критичных доменов (payment.company.com).
• Внутренний трафик между микросервисами идет напрямую без проксирования.

Для финансовых организаций с гибридной инфраструктурой

• Правила для конкретных IP критичных систем.
• Дифференцированная фильтрация для публичных и внутренних сервисов.
• Соответствие регуляторным требованиям за счет сохранения DNS‑инфраструктуры.

Технология защиты L7 без смены A‑записей решает ключевые проблемы классического reverse proxy:

• устраняет задержки, связанные с обновлением DNS;
• защищает от целевых атак на реальный IP;
• обеспечивает мгновенное включение/отключение защиты;
• снижает операционные издержки за счет гибкой модели биллинга без дополнительных доплат за неочищенный трафик.

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

Базовые рекомендации специалистов DDoS-Guard для построения защиты проекта

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

Избыточность — это хорошо. Создайте резервные копии критически важных компонентов:

• дублируйте каналы подключения;
• работайте с несколькими операторами связи;
• предусмотрите резервное оборудование;
• обеспечьте кадровое резервирование.

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

«В современных условиях защита от DDoS — это обязательный элемент ИТ-инфраструктуры. Мы видим растущий интерес к этому классу решений со стороны наших заказчиков. Сотрудничество с DDoS-Guard позволяет нам отвечать на этот запрос, предлагая проверенные инструменты для построения комплексной защиты. Решения вендора уже доказали свою эффективность и надежность в отражении самых сложных современных атак», — менеджер направления развития новых решений департамента информационной безопасности Softline Надежда Макарова.