Защита от DDoS своими силами: что настроить на сервере и у провайдера до подключения платной защиты

Отсутствие DDoS-атак в прошлом часто воспринимают как подтверждение безопасности. На практике это означает лишь то, что организация пока не столкнулась с атакой или не распознала ее. Целью может стать практически любой публичный сервис – интернет-магазин, личный кабинет, корпоративный сайт, DNS-инфраструктура или внешний канал связи.

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

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

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

Пять шагов, которые можно сделать своими силами

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

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

Поэтому самостоятельную подготовку к DDoS-атаке можно разбить на пять последовательных шагов.

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

Второй шаг – сокращение поверхности атаки и укрепление периметра. Нужно закрыть ненужные порты и протоколы, ограничить административный доступ, проверить межсетевые экраны, настроить защиту от SYN-flood, тайм-ауты, лимиты новых и одновременных соединений, а также фильтрацию некорректных пакетов. Важно оставить доступными из интернета только самые необходимые сервисы и добиться, чтобы аномальный трафик ограничивался без падения всей системы.

Третий шаг – защита приложений и API. Необходимо ограничить частоту запросов и число соединений, настроить тайм-ауты, допустимые размеры запросов и кэширование, а для ресурсоемких операций установить отдельные лимиты. При перегрузке приложение должно уметь отклонять часть запросов, например, ответом HTTP 429, и при этом продолжать обслуживать остальных пользователей. Сложность здесь в том, что DDoS-атаку трудно отличить от наплыва клиентов, поэтому нельзя допускать ошибки в лимитах.

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

Пятый шаг – подготовка взаимодействия с провайдером. Нужно уточнить пропускную способность канала, контакты круглосуточной поддержки и доступность ACL, BGP FlowSpec или blackhole, а также заранее согласовать формат заявки и процедуру экстренной эскалации. В результате у команды должны быть проверенные контакты, перечень доступных действий и понимание времени реакции оператора. При этом возможности провайдера могут ограничиваться полной блокировкой атакуемого IP-адреса: сеть разгрузится, но сам сервис останется недоступным.

Где искать узкие места в инфраструктуре

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

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

Для веб-сервера и обратного прокси важны максимальное количество соединений и запросов, ограничения их частоты с учетом допустимых кратковременных всплесков, тайм-ауты чтения и ожидания ответа, размеры заголовков и тела запроса, параметры keep-alive и кэширование. Для тяжелых API нужны отдельные лимиты. При перегрузке веб-сервер должен отвечать, например, ошибками 429 или 503, но продолжать обслуживать остальных пользователей.

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

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

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

Что настроить у провайдера

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

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

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

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

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

Другой риск – блокировка только по IP. За одним адресом мобильного оператора, корпоративного NAT или прокси могут находиться тысячи пользователей, поэтому блокировка такого источника затронет сразу большую группу клиентов. При этом атакующий может постоянно менять адреса, превращая ручное пополнение черных списков в бесконечную гонку.

Не менее опасны слишком широкие запреты. Блокировка целых стран, автономных систем, всего UDP-, ICMP- или фрагментированного трафика может нарушить работу легитимных сервисов. Полный запрет ICMP способен создать проблемы с определением допустимого размера пакета, а блокировка UDP – затронуть DNS или VPN. Такие меры допустимы как временные аварийные действия, если команда понимает их последствия.

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

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

Авторы: Алексей Бушукин, старший архитектор систем информационной безопасности компании «Гарда», Михаил Коган, руководитель группы сопровождения продаж сетевой безопасности компании «Гарда».