DDoS-защита выделенного сервера: что означает UNLIMITED и что нужно уточнить отдельно

MAATRIX · Выделенные серверы · Статья 45 из 48

В карточке сервера написано «1 Гбит/с UNLIMITED». Для обычной передачи файлов это приятная строка. Но если прочитать её как «сервер выдержит любой входящий поток», получится обещание, которого в этих словах нет.

UNLIMITED описывает условия учёта трафика в тарифе. Пропускная способность порта описывает скорость соединения. DDoS-защита описывает меры против исчерпания ресурсов. Эти свойства могут сочетаться в одной услуге, но не следуют друг из друга. Разобраться в различиях лучше до того, как график сети начнёт напоминать отвесную стену.

Три вопроса к одной строке тарифа

Первый вопрос: сколько данных разрешено передать и по каким правилам считается использование? Здесь важны условия тарифа, допустимые сценарии, возможная политика разумного использования и ограничения отдельных направлений. Само слово UNLIMITED не отменяет договор и технические пределы инфраструктуры.

Второй вопрос: какую скорость предоставляет порт и что гарантируется? 1 Гбит/с — не бесконечность, а конкретный порядок пропускной способности. Кроме того, скорость между вашим сервером и пользователем зависит от обеих сторон и маршрута. Локальная скорость интерфейса не обещает такой же результат через любой внешний канал.

Третий вопрос: где и как отсекается нежелательный поток? Если фильтрация начинается только на самом сервере, она уже не поможет освободить переполненное соединение перед ним. Для крупных сетевых атак нужна возможность обрабатывать или отбрасывать трафик выше по сети, до узкого места.

В предоставленном прайсе все выделенные серверы MAATRIX имеют обозначение 1 Гбит/с UNLIMITED. На главной странице сервиса также упоминается Anti-DDoS на уровне дата-центра. Однако по проверенным публичным материалам нельзя установить защищаемую мощность, протоколы, режим включения и договорные гарантии для каждого dedicated-тарифа. Эти параметры необходимо уточнять по конкретному заказу.

Такое уточнение не формальность. Сайт, WireGuard, игровой сервер и почта используют разные протоколы и могут требовать разной фильтрации. Ответ «защита есть» без указания того, что именно она защищает, оставляет главный вопрос открытым.

Почему сервер падает при свободном процессоре или свободном канале

Представим условный порт с пределом 1 Гбит/с. Если нежелательный входящий поток заполняет доступную полосу до сервера, полезные пакеты начинают теряться или ждать. CPU при этом может быть сравнительно свободен: он не успевает получить значительную часть трафика. Покупка NECROPOLIS вместо ANKH не расширит этот участок маршрута сама по себе.

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

На прикладном уровне картина противоположная. Потока может быть немного, но запросы вызывают дорогие вычисления, поиск, генерацию документов или обращения к базе. Канал свободен, а рабочие процессы и соединения с СУБД закончились. Простой сетевой фильтр не всегда отличит такой запрос от обычного действия пользователя.

Сетевые и прикладные механизмы защиты поэтому рассматриваются отдельно. Например, в документации Cloudflare DDoS Protection разделены сетевые уровни и HTTP-защита. Это пример устройства защитного сервиса, а не характеристика арендуемого сервера MAATRIX.

Наконец, похожие симптомы бывают без атаки: рекламная кампания, ошибка клиента с частыми повторными запросами, тяжёлый отчёт или неисправная интеграция. До окончательного вывода сопоставьте трафик, запросы, CPU, память, дисковую задержку и состояние базы. Назвать любое замедление DDoS удобно, но для восстановления мало полезно.

Подробнее о случае, когда свободная сеть соседствует с перегруженной базой, написано в статье о DDoS на API. Она помогает искать фактический исчерпанный ресурс, а не лечить график, который первым попался на глаза.

Сайт, игра и VPN требуют разного разговора о защите

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

Если исходный адрес сервера доступен напрямую, часть запросов может обойти защиту. Поэтому нужно продумать ограничение прямого доступа, служебные интеграции, мониторинг и альтернативные имена. Размещённая рядом почта или другая служба тоже может раскрывать адрес и иметь собственный путь нагрузки. Само изменение DNS не создаёт универсальный щит вокруг всех портов.

Для игры или VPN обычного HTTP-прокси недостаточно. Нужен сервис, который поддерживает соответствующий TCP- или UDP-трафик и особенности приложения. У коммерческих решений набор протоколов и условия различаются; например, Cloudflare Spectrum отдельно описывает работу с TCP/UDP-приложениями. Применимость и стоимость всегда проверяются по конкретной услуге.

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

Для VPN учитывайте легитимные длительные соединения и изменение адресов пользователей. Грубое ограничение по IP способно одновременно заблокировать множество людей за одним NAT. Аналогичная проблема бывает у корпоративных клиентов сайта: один внешний адрес не означает одного человека.

Для почты, DNS и других служб также нужны свои условия. Не распространяйте обещание защиты веб-сайта на весь сервер автоматически. Удобно составить перечень публичных сервисов и напротив каждого записать: механизм защиты, допустимый режим работы, контакт поддержки и порядок действий при блокировке.

Вопросы, которые превращают «Anti-DDoS» в понятную услугу

Начните с охвата. Какие адреса и протоколы защищаются? Постоянно ли трафик проходит фильтрацию или она включается после обнаружения? Требуется ли изменение DNS, маршрутов или конфигурации приложения? Есть ли отдельные требования к исходному серверу?

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

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

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

Фиксируйте подтверждённые условия письменно. Для критичного сервиса полезно разделить техническое описание защиты и договорные обязательства по доступности. Компенсация, если она предусмотрена, не делает сервис работоспособным во время инцидента; её роль другая.

Что вы можете подготовить на своей стороне

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

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

Ограничение частоты запросов выбирайте по поведению приложения. У Nginx есть соответствующий модуль limit_req, в том числе режим наблюдения без блокировки. Но универсальное значение «столько-то запросов на IP всем» способно отсечь нормальных пользователей. Особенно важно учитывать прокси и корректное определение адреса клиента только от доверенного источника.

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

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

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

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

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

UNLIMITED полезен, когда вы понимаете его место в договоре. Он говорит об условиях трафика, а защищённость сервиса складывается из фильтрации, архитектуры и готовности команды. Хороший ответ на вопрос «выдержит ли сервер?» начинается с уточнения: какую нагрузку, на какой протокол и при каких условиях.

Все материалы о выделенных серверах