При выборе colocation владельцы собственного сервера обычно начинают с понятных вещей: сколько стоит 1U, какая мощность включена, сколько дают трафика и можно ли подключить два блока питания. Защита от DDoS нередко остаётся где-то внизу списка, особенно если дата-центр пишет, что фильтрация уже включена в услугу. На практике одной этой фразы недостаточно.
Мощный сетевой канал дата-центра сам по себе не защищает конкретный сервер от атаки. Если вредоносный поток успевает полностью занять доступную полосу до вашей машины, сайт становится недоступным даже при исправном CPU, свободной памяти и работающем RAID. Настоящая защита должна отбрасывать лишний трафик раньше, чем он превратит подключение сервера в узкое место.
Поэтому при коммерческом colocation важно выяснить не только есть ли DDoS-защита, но и что именно оператор понимает под этим названием. Базовая фильтрация сетевого мусора, автоматическая очистка крупных атак и защита HTTP-приложения от сложного флуда — это разные возможности.
Для небольшого корпоративного сайта максимальный уровень защиты может быть избыточным. Для игрового сервиса, интернет-магазина, публичного API или проекта, который уже подвергался атакам, условия фильтрации могут оказаться одним из основных критериев выбора ЦОД.
Как должна работать DDoS-защита при colocation
DDoS-атака пытается лишить реальных пользователей доступа к сервису за счёт большого количества искусственного трафика или запросов. Сам сервер может быть достаточно мощным, но атакующий стремится перегрузить один из ресурсов раньше него.
Самый очевидный вариант — заполнить сетевой канал. Допустим, сервер подключён на 1 Гбит/с. Если до него начинает доходить несколько гигабит вредоносного трафика, ограничением становится уже не производительность машины, а её подключение.
Установленный на самом сервере firewall в такой ситуации помогает мало. Он способен быстро отбрасывать нежелательные пакеты, но эти пакеты уже прошли через внешний канал и заняли его пропускную способность.
Поэтому защита от объёмных атак должна работать внутри сети оператора или ещё выше, до того как трафик попадёт на ограниченный порт клиента.
Провайдер анализирует входящие потоки, обнаруживает аномалию и перенаправляет или сразу пропускает трафик через инфраструктуру очистки. Нормальные пакеты возвращаются к серверу, а вредоносные отбрасываются.
Что означает базовая защита от DDoS
У разных операторов это выражение может означать совершенно разные вещи.
Иногда под базовой защитой понимается автоматическая фильтрация распространённых атак на сетевом и транспортном уровнях. Она способна отсекать SYN flood, UDP flood, ICMP flood и другие типовые варианты.
Для большинства обычных проектов подобный уровень уже полезен. Самые примитивные атаки не доходят до сервера и не требуют ручного вмешательства администратора.
Но базовая защита не обязательно означает полноценную фильтрацию любых объёмов трафика. У оператора могут существовать лимиты по мощности атаки или условия, при которых защита перестаёт предоставляться в рамках стандартного тарифа.
Например, после определённого порога IP временно блокируется, чтобы атака не влияла на остальных клиентов. Такой механизм называется blackhole или null route.
С точки зрения сети оператора это действительно защищает инфраструктуру. С точки зрения владельца сайта результат менее приятный: атакуемый IP становится полностью недоступным, включая обычных пользователей.
Поэтому один из самых важных вопросов перед colocation — что произойдёт после превышения возможностей базовой фильтрации.
Продолжится автоматическая очистка? Появится дополнительная тарификация? Понадобится подключить расширенную услугу? Или оператор просто отключит атакуемый адрес?
Эту информацию лучше получить до первой атаки.
L3 и L4 защита не заменяет защиту самого сайта
Большая часть сетевой DDoS-защиты работает на уровнях L3 и L4. Она анализирует IP-пакеты, протоколы TCP и UDP, количество соединений и другие сетевые характеристики.
Такая фильтрация прекрасно подходит против атак, задача которых заключается в заполнении канала или исчерпании таблицы соединений.
Но существует другой тип нагрузки. Боты могут отправлять вполне корректные HTTP-запросы к тяжёлой странице сайта. Каждый запрос выглядит почти как обычный посетитель, но таких обращений становится настолько много, что приложение и база данных перегружаются.
Сетевой фильтр может не считать такой трафик подозрительным. TCP-соединения корректны, HTTP-запросы формально допустимы, а проблема возникает уже внутри приложения.
Для защиты от такого HTTP flood используется уровень L7, то есть прикладная фильтрация.
Она часто реализуется через CDN, WAF, reverse proxy или отдельный сервис защиты, расположенный перед сайтом.
Поэтому наличие мощной L3/L4-защиты в ЦОД не означает, что WordPress или интернет-магазин невозможно положить большим количеством тяжёлых запросов.
Для коммерческого сайта обычно разумна комбинация. Сетевой уровень дата-центра защищает сам канал и сервер от объёмных атак, а внешний CDN или WAF помогает фильтровать прикладной трафик.
Не каждому проекту нужен дорогой специализированный anti-DDoS на всех уровнях. Но понимать разделение ответственности полезно.
Что спросить у ЦОД перед заказом защищённого colocation
Первый вопрос — включена ли защита в базовый тариф или является отдельной услугой.
Если она включена, нужно узнать её ограничения. Само слово бесплатно ничего не говорит о возможностях фильтрации.
Полезно уточнить максимальную мощность атаки, которую инфраструктура способна очищать без отключения IP клиента. Оператор может не публиковать абсолютно все технические параметры, но общую модель работы обычно объяснить способен.
Второй вопрос — защита включается автоматически или по запросу.
Автоматический режим удобнее для публичного сайта. Система обнаруживает аномалию и начинает очистку без участия клиента.
Если для переключения трафика нужно создать заявку в поддержку, первые минуты или десятки минут атаки могут сопровождаться недоступностью.
Для проекта, который редко подвергается атакам и спокойно переносит небольшой простой, это может быть приемлемо. Для критичного сервиса лучше автоматическая реакция.
Третий вопрос — сколько занимает переключение на очистку.
Даже автоматическая система не всегда реагирует мгновенно. Сначала нужно обнаружить изменение трафика и классифицировать его как атаку.
Слишком чувствительная система сама создаёт проблемы, принимая обычный всплеск посещаемости за DDoS. Слишком медленная позволяет атаке заметно влиять на сервис до начала фильтрации.
Поэтому полезно узнать, как оператор в общих чертах обнаруживает атаки и есть ли заметное окно между началом события и очисткой.
Четвёртый вопрос — меняется ли IP сервера при использовании защиты.
В некоторых схемах защищённый адрес выдаётся отдельно. В других фильтрация работает непосредственно для существующей подсети клиента.
Если проект использует IP в whitelist партнёров, VPN, API и других интеграциях, возможное изменение адреса нужно учитывать заранее.
Пятый вопрос — защищается только IPv4 или IPv6 тоже.
Сайт может иметь одновременно A и AAAA-записи. Если защищён только IPv4, злоумышленник потенциально способен атаковать IPv6-путь напрямую.
После подключения dual stack политика безопасности должна быть одинаково продумана для обоих протоколов.
Шестой момент — какие протоколы разрешены при защите.
Для обычного сайта всё довольно просто: HTTP и HTTPS. Но физический сервер может одновременно обслуживать VPN, игровые порты, VoIP, нестандартные TCP или UDP-сервисы.
Не каждая схема очистки одинаково хорошо работает со всеми протоколами.
Если проект использует нестандартный трафик, его лучше описать оператору до заключения договора.
Особенно это важно для игровых серверов. Они часто работают по UDP, чувствительны к задержке и сами являются распространённой целью атак.
Фильтрация должна защищать сервис, не превращая нормальное соединение пользователей в нестабильное.
Следующий параметр — задержка после включения очистки.
Если трафик отправляется через удалённый центр фильтрации, маршрут может стать длиннее. Для сайта дополнительные миллисекунды обычно не критичны. Для игры или другого интерактивного приложения задержка уже имеет значение.
Полезно узнать, где расположена инфраструктура очистки и меняется ли маршрут постоянно или только во время атаки.
Есть операторы, которые фильтруют трафик всегда. У других обычный поток идёт напрямую, а при обнаружении атаки перенаправляется через специальные узлы.
Оба подхода способны нормально работать. Для клиента важен результат: стабильная связь и понятная задержка.
Нужно посмотреть и на тарификацию.
Базовая защита может входить в colocation, а расширенная рассчитываться отдельно. Цена иногда зависит от выделенного канала, защищаемых IP или уровня услуги.
Самая неприятная модель для клиента — непредсказуемая тарификация по фактическому объёму атакующего трафика без понятного верхнего предела.
Если DDoS способен одновременно вывести сайт из строя и создать огромный счёт за входящий трафик, защита организована не лучшим для бизнеса образом.
Поэтому стоит отдельно спросить, учитывается ли отфильтрованный вредоносный трафик в месячном лимите.
Для тарифов с ограниченным количеством терабайт это особенно важно.
Нормальный пользовательский трафик после фильтрации и гигантский поток атаки — совершенно разные вещи, и коммерческая модель должна это учитывать.
Полезны и отчёты об атаках. После инцидента администратору желательно видеть хотя бы время начала, длительность, примерную мощность и тип обнаруженного трафика.
Это позволяет понимать, насколько регулярно атакуется сервис и есть ли смысл усиливать защиту.
Если оператор предоставляет только сообщение атака была заблокирована без какой-либо дополнительной информации, анализировать инфраструктуру сложнее.
При серьёзных событиях может быть полезна связь с технической поддержкой или специализированной anti-DDoS командой.
Обычный менеджер colocation не обязан глубоко разбираться в атаке. Важно, чтобы у оператора существовала понятная процедура эскалации.
Перед заказом я бы также уточнила, защищён ли management-интерфейс.
IPMI, iDRAC или iLO вообще не стоит публиковать напрямую в интернет без необходимости. Лучше использовать отдельную management-сеть, VPN или другие ограничения доступа.
DDoS-защита публичного IP сайта не превращает плохо защищённый BMC в безопасный сервис.
Это уже не вопрос объёмной атаки, а обычной сетевой безопасности.
На основном сервере всё равно должен работать локальный firewall. Он не заменяет внешнюю DDoS-фильтрацию, но ограничивает доступ к ненужным портам.
Если машине нужны только HTTPS, SSH из административной сети и несколько внутренних сервисов, остальные внешние подключения лучше закрыть.
Так уменьшается поверхность атаки и количество случайного сетевого мусора.
При выборе дата-центра DDoS-защиту стоит оценивать вместе с общей сетевой инфраструктурой. Хорошая фильтрация мало помогает, если площадка имеет слабую связность или единственную внешнюю точку отказа.
И наоборот, огромные каналы дата-центра не заменяют фильтрацию конкретного клиента.
Для простого сайта требования обычно можно оставить умеренными. Автоматическая базовая L3/L4-защита, достаточная ёмкость сети и возможность быстро подключить расширенную фильтрацию при необходимости уже дают нормальный уровень.
Для проекта из зоны повышенного риска подход другой.
Если сервер регулярно атакуют, полезно получить условия защиты в письменном виде ещё до переезда: лимиты, реакцию на превышение, наличие L7, поддержку используемых протоколов и правила тарификации.
Особенно внимательно я бы относилась к формулировке защита без ограничений. В инфраструктуре всегда существуют физические пределы. Намного лучше, когда оператор понятно объясняет архитектуру и сценарии реакции, чем обещает абсолютную защиту от любой возможной атаки.
Нужно учитывать и резервный план.
Что произойдёт, если конкретный IP всё-таки будет временно заблокирован? Можно ли быстро получить новый? Есть ли второй сервер или CDN? Можно ли переключить DNS?
Для небольшого бизнеса такой сценарий может быть излишним. Но критичный сервис не должен зависеть от одной технологии безопасности.
CDN особенно полезен публичным сайтам. Он кэширует статические данные, принимает пользовательские подключения на распределённых узлах и способен скрыть реальный IP origin-сервера.
Но это работает только если origin действительно закрыт от прямого доступа извне. Если его настоящий IP легко обнаружить и он доступен каждому, атакующий способен обойти CDN и направить трафик непосредственно в ЦОД.
Поэтому при подобной архитектуре firewall сервера должен принимать веб-трафик только от сетей используемого reverse proxy или CDN, если конкретная схема это позволяет.
Для API и динамических приложений возможности CDN зависят от сервиса, но принцип остаётся тем же: внешний защитный слой и сетевая фильтрация ЦОД дополняют друг друга.
Не нужно считать DDoS единственной угрозой для colocation. Серверу по-прежнему нужны обновления, нормальные пароли, ограниченный административный доступ, резервные копии и мониторинг.
Защита от многогигабитной атаки никак не поможет после компрометации SSH из-за слабого пароля.
Но сетевой DDoS относится именно к тем угрозам, которые невозможно полноценно решить только внутри собственной машины. Если внешний канал уже забит, локальное программное обеспечение почти ничего не может сделать.
Поэтому выбор защиты является частью выбора самого colocation-провайдера.
Перед заключением договора достаточно получить ответы на несколько практических вопросов: какая защита входит в тариф, на каких уровнях она работает, включается ли автоматически, что происходит после превышения лимитов, защищается ли IPv6 и учитывается ли вредоносный трафик в обычной квоте.
Если ответы соответствуют риску проекта, покупать самый дорогой anti-DDoS пакет необязательно.
Если оператор вообще не может объяснить, что произойдёт при реальной атаке, экономия на размещении может оказаться слишком рискованной для публичного коммерческого сервиса.
Хорошая DDoS-защита большую часть времени никак себя не проявляет. Сервер просто получает обычный трафик. Но в тот день, когда на его IP приходит поток, в несколько раз превышающий возможности собственного порта, именно инфраструктура перед сервером определяет, продолжит ли сайт работать для настоящих пользователей.
