DDoS-атаки на уровне инфраструктуры: как хостинг-провайдеры защищают клиентов

Инфраструктурный DDoS — это не «чуть-чуть больше трафика», а попытка забить канал, перегрузить сетевое оборудование, исчерпать таблицы состояний и сделать сервис недоступным еще до того, как запросы дойдут до сервера. Поэтому защита у хостинг-провайдера строится не вокруг одного «магического фильтра», а вокруг нескольких уровней: от магистрали до веб-приложения. И если вы думаете, что анти-DDoS на VPS решает проблему, — нет, решает только связка мер на разных уровнях стекa.

Что такое инфраструктурный DDoS и чем он опасен

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

Чаще всего встречаются три сценария:

• Volumetric-атаки — пытаются забить канал объемом трафика. Это классика жанра: UDP-флуды, DNS amplification, NTP reflection. Главная метрика здесь — гигабиты в секунду, а не число запросов. Если канал физически исчерпан, дальше можно ничего не лечить.
• Protocol-атаки — бьют по сетевым протоколам и состояниям соединений. SYN-flood, например, переполняет таблицу conntrack на пограничных устройствах или балансировщиках: новые соединения не устанавливаются, хотя полоса еще свободна. Это как раз тот случай, когда смотреть только на bandwidth — ошибка.
• L7-атаки — имитируют легитимные HTTP-запросы и нагружают уже приложение. Здесь каждый запрос выглядит почти как настоящий, только идет с тысяч ботов. Против таких атак сетевые фильтры первого уровня бессильны — нужен анализ поведения.

Для хостинг-провайдера проблема в том, что атака начинается раньше сервера клиента: если упал аплинк, то внутри дата-центра уже нечего «лечить» на стороне VPS или сайта. Именно поэтому нормальный анти-DDoS всегда работает на несколько шагов выше, чем тарифная сетка.

Как провайдеры защищают клиентов: слои защиты

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

1. Защита на магистрали и у аплинков

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

Что важно проверять у провайдера:

• есть ли запас по uplink capacity — номинальной полосы недостаточно, нужен пиковый запас минимум в 2–3 раза;
• сеть должна выдерживать всплеск трафика без мгновенной деградации соседних клиентов;
• фильтрация должна срабатывать быстро, иначе канал просто «забьется» раньше, чем сработает автоматика.

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

2. Scrubbing center — «мойка» трафика

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

Это особенно эффективно против:

• больших UDP-флудов;
• SYN-flood;
• атак на протоколы;
• части Layer 7-сканеров и ботов.

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

3. Anycast и распределение нагрузки

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

Плюсы:

• сложнее «положить» один конкретный сервер;
• атака распределяется по нескольким узлам;
• повышается устойчивость к всплескам трафика.

Минус очевиден: anycast требует зрелой сетевой архитектуры и не решает проблему сам по себе, если узлы слабы или каналы недокормлены. Плюс с TCP есть отдельная история: соединение может «мигрировать» между узлами, если BGP-политика не настроена аккуратно, и тогда клиент получает обрывы сессий. Для HTTP-запросов это терпимо, для WebSocket и стриминга — уже больно.

4. BGP blackholing и rerouting

Когда атака слишком сильная или точечная защита не успевает, провайдер может использовать BGP-механизмы: перенаправить трафик в очистку или, в крайнем случае, «погасить» маршрут через blackhole.

Важно понимать разницу:

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

Blackhole — это аварийная мера, а не полноценная защита. Она спасает инфраструктуру, но вместе с атакой выбрасывает и легитимных пользователей. Я видел кейсы, когда неопытный админ включал RTBH (Remotely Triggered Blackhole) на весь анонс клиента — и получал жалобу не на атаку, а на то, что сайт полностью пропал из интернета для всех, включая владельца.

5. Rate limiting и connection limiting

На сетевом и прикладном уровне провайдеры ограничивают частоту запросов и число одновременных соединений от одного источника. Это помогает против агрессивных ботов, простых флудов и некоторых L7-сценариев.

Обычно применяются:

• лимит пакетов в секунду;
• лимит запросов в секунду;
• лимит соединений с одного IP;
• ограничения на создание новых сессий.

Такая защита полезна, но не всесильна: распределенная атака с тысячами IP может обойти простые лимиты. В этом случае на помощь приходит уже не лимитирование, а поведенческий анализ, который работает на L7.

Чем анти-DDoS у хостинга отличается от защиты на стороне сайта

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

Если канал уже забит, WAF на VPS почти бесполезен: запросы до него просто не дойдут. Поэтому инфраструктурная защита нужна раньше, чем веб-защита. И именно поэтому нормальные провайдеры не продают «анти-DDoS» как одну кнопку — это всегда комбинация из нескольких уровней, и каждый закрывает свой класс атак.

Как понять, что у провайдера защита не «для галочки»

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

Практический чек-лист

• Указаны ли уровни защиты: L3, L4, L7.
• Есть ли собственная фильтрация или внешний scrubbing-партнер.
• Описаны ли лимиты: Gbps, PPS, соединения, время реакции.
• Есть ли автоматическое включение защиты или только ручной режим.
• Что происходит при очень сильной атаке: фильтрация, деградация, blackhole.
• Есть ли прозрачные условия по легитимному трафику и false positive.
• Поддерживается ли защита для DNS, почты, VPS и выделенных серверов отдельно.

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

Какие архитектурные решения реально помогают провайдерам

У сильного хостинг-провайдера защита строится не только на фильтре, но и на архитектуре сети. Фильтр — это тактическое решение, а архитектура — стратегическое.

Что должно быть в зрелой инфраструктуре

• запас по каналу и пиковым нагрузкам;
• несколько upstream-провайдеров;
• автоматическое перераспределение трафика;
• изоляция сервисов клиентов;
• защита DNS и control plane отдельно от пользовательских VPS;
• мониторинг PPS, bandwidth, conntrack и аномалий по портам.

Если упрощать, задача провайдера — не «поймать каждый пакет», а не дать атаке добраться до критических точек. И здесь важен мониторинг: вы не можете защитить то, чего не видите. Без детальной телеметрии по PPS и conntrack атака часто обнаруживается уже после того, как сервис лег.

Российский контекст: на что обращать внимание

На российском рынке анти-DDoS часто идет в составе инфраструктурного пакета или как отдельная услуга. Это связано с тем, что для локальных клиентов важны не только каналы и фильтрация, но и география размещения, юрисдикция, доступность русскоязычной поддержки и понятные SLA.

Для российских проектов особенно важны:

• дата-центр и маршрут до аудитории;
• наличие защиты на уровне магистрали;
• понятная схема переключения при атаке;
• отсутствие завязки на единственный внешний сервис;
• предсказуемая работа DNS и почты во время инцидента.

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

Что может сделать сам клиент до атаки

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

Минимум, который стоит сделать заранее

• включить кэширование там, где это возможно;
• выносить статические ресурсы в CDN;
• закрыть лишние порты;
• ограничить доступ к панели управления по IP;
• настроить rate limiting на nginx или другом reverse proxy;
• разделить публичные и служебные сервисы;
• иметь план переключения DNS и резервный доступ к инфраструктуре.

Это не заменяет анти-DDoS, но снижает шанс, что атака превратится в длительный простой. И да, резервный доступ — это не роскошь: когда основная панель лежит под атакой, второй канал управления часто оказывается единственным способом что-то исправить.

Типовые ошибки при выборе хостинга с защитой

• Покупать тариф, где «защита включена», но не уточнять ее параметры.
• Путать защиту сайта с защитой канала.
• Не проверять, защищены ли DNS и панель управления.
• Игнорировать лимиты по PPS и connection rate.
• Не иметь запасного сценария на случай blackhole.
• Выбирать провайдера только по цене, без понимания архитектуры сети.

Пошагово: как оценить провайдера перед запуском проекта

1. Уточнить, на каком уровне работает защита: сеть, L4, L7.
2. Попросить описать сценарий при атаке 1–10 Гбит/с и выше.
3. Проверить, есть ли scrubbing center или upstream-анти-DDoS.
4. Спросить, как защищены DNS, почта и панель управления.
5. Уточнить, что произойдет при перегрузке: фильтрация, ограничение, blackhole.
6. Посмотреть, есть ли публичные лимиты и SLA.
7. Провести небольшой тестовый запуск и наблюдать метрики сети, а не только uptime.

Краткий вывод

Хостинг-провайдер защищает клиентов от DDoS не одним средством, а комбинацией сетевых, маршрутизационных и прикладных механизмов. Надежная схема включает scrubbing, anycast, BGP-маневры, лимитирование и понятную архитектуру отказоустойчивости. Чем прозрачнее провайдер объясняет уровни защиты и ограничения, тем выше шанс, что в реальной атаке сайт останется доступным. И главное — защита от DDoS это не продукт, а процесс: сети, фильтры и сценарии должны постоянно пересматриваться, потому что атакующие тоже не стоят на месте.

FAQ

Что такое инфраструктурный DDoS простыми словами?

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

Можно ли защититься только WAF’ом?

Нет. WAF помогает против HTTP-атак, но не спасет, если забит канал или атакована маршрутизация. WAF работает на L7, а инфраструктурные атаки бьют на L3–L4, где у WAF нет доступа.

Что лучше: anycast или scrubbing?

Обычно они дополняют друг друга. Anycast распределяет трафик, scrubbing очищает его от вредоносных пакетов. Одно без другого работает, но в полсилы.

Почему иногда провайдер уводит трафик в blackhole?

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

Достаточно ли защиты, включенной в тариф?

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