Сайт не принимает заказы, сотрудники не подключаются к сервисам, клиенты видят ошибки. DDoS направлен на недоступность. Защиту нужно строить там, где возникает перегрузка: в канале связи, сетевом оборудовании или приложении.
Сохранить доступность
Помочь клиентам и сотрудникам пользоваться сервисами во время атаки.
Защитить рабочие процессы
Учитывать не только сайт, но и DNS, VPN, почту и другие важные подключения.
Сократить время реакции
Заранее определить контакты, полномочия и порядок включения защитных мер.
Проверять результат
Оценивать работу приложения для пользователей, а не только объём отфильтрованного трафика.
Что такое DDoS и зачем его организуют
DDoS — Distributed Denial of Service, распределённая атака на отказ в обслуживании. Трафик или запросы поступают из множества источников и расходуют ресурсы цели. Обычным пользователям не хватает полосы связи, соединений или производительности сервиса.
Организатор может стремиться сорвать работу, оказать давление или вымогать деньги под угрозой остановки. Конкретный мотив и источник нельзя установить только по факту сбоя. DDoS-вымогательство также не тождественно шифрованию данных программой-вымогателем.
Общее объяснение: классы DDoS и DDoS-вымогательство.
Три группы атак — три разных узких места
Объёмные атаки
- Цель — заполнить доступную полосу связи
- Примеры: UDP-флуд, отражённый и усиленный трафик
Смотреть: загрузку канала и объём трафика в битах в секунду.
Атаки на протоколы и соединения
- Расходуют ресурсы сетевых устройств и серверов
- Пример: SYN-флуд, создающий нагрузку на обработку соединений
Смотреть: пакеты, новые соединения и заполнение таблиц сессий.
Атаки на приложение — L7
- Перегружают обработку запросов к сервису
- Пример: множество HTTP-запросов к ресурсоёмким операциям
Смотреть: запросы, задержки, ошибки, ресурсы приложения и СУБД.
Группы могут сочетаться: сначала перегружается сеть, затем растёт нагрузка на приложение. Отражение и усиление означают, что часть сторонних систем используется для направления увеличенного потока к цели. Название метода не заменяет измерение фактической нагрузки.
Как отличить атаку от обычного сбоя
- Канал и сеть. Есть ли рост трафика, потерь, числа пакетов и новых соединений; что видит провайдер.
- Приложение. Какие URL и операции вызывают нагрузку, как меняются время ответа и ошибки, хватает ли ресурсов СУБД.
- Доступность извне. Открывается ли ресурс из разных сетей; работает ли DNS; затронут один сервис или несколько.
- Изменения и нормальные пики. Совпало ли начало сбоя с обновлением, рекламной кампанией, пакетной обработкой или ошибкой интеграции.
Сохраните время начала, графики, характер ошибок и журналы. Обычная нагрузка, проблема провайдера и медленный запрос к базе могут выглядеть похоже. Решение о фильтрации принимают по совокупности данных.
Какие последствия учитывать бизнесу
- Клиенты не могут заказать товар, оплатить или отправить заявку.
- Недоступны личные кабинеты, обмен с партнёрами и API.
- Сотрудники теряют доступ к VPN, опубликованным сервисам и другим рабочим инструментам.
- Команда тратит время на разбор, обращения и восстановление нормальной работы.
Оцените, какие операции остановятся и как долго компания может работать в таком режиме. Это помогает выбрать объём защиты и заранее подготовить альтернативные каналы взаимодействия.
Какие способы защиты используют
Очистка трафика выше по сети
- Фильтрация до узкого канала компании
- Защита IP-ресурсов и протоколов по согласованной схеме
Для объёмных и сетевых атак; подключение зависит от адресов, провайдера и маршрутизации.
Обратный прокси для сайта и API
- Публичные запросы сначала приходят на защитную платформу
- До сервера приложения передаётся обработанный поток
Для HTTP/HTTPS-сервисов; отдельно проверяют сертификаты, API и отсутствие обхода прокси.
WAF и защита от ботов
- Проверки запросов и признаков автоматизации
- Правила для важных URL, сессий и действий
Дополняют anti-DDoS, но не равнозначны защите любого протокола или канала.
Ограничение нагрузки
- Пороги запросов и соединений
- Правила с учётом клиентов, интеграций и нормальных пиков
Помогает сдержать часть нагрузки; один лимит на IP не решает все распределённые атаки.
CDN и кэширование
- Выдача кэшируемого содержимого ближе к пользователю
- Снижение части обращений к серверу-источнику
Полезны для статики; динамический поиск, вход и API требуют отдельной оценки.
Защита DNS и зависимостей
- Отказоустойчивые авторитетные DNS-серверы
- Проверка внешней авторизации, API и других критичных связей
Сайт может быть исправен, но оставаться недоступным из-за атакованной зависимости.
Локальные лимиты, кэш и запас мощности полезны в общей схеме. Но если вредоносный поток заполнил входящий канал до вашей сети, фильтр внутри компании не вернёт ему свободную полосу.
Защита сайта и защита сети подключаются по-разному
Сайт или веб-API
Прокси · anti-DDoS · прикладные правила
Доступ по согласованному маршруту
IP-инфраструктура и сетевые сервисы
У провайдера или в специализированной сети
Согласованные адреса и протоколы
Для TCP-прокси, HTTP-прокси и защиты UDP разные возможности. Например, документация Qrator отдельно описывает границы TCP-прокси: он не выполняет полноценную обработку веб-приложения, необходимую для WAF и антибота.
Примеры решений и провайдеров
Варианты для первоначального рассмотрения. У каждого проверяйте конкретную услугу, покрытие и условия подключения.
Qrator Labs
HTTP reverse proxy для веб-сервисов и другие варианты защиты инфраструктуры, включая TCP-прокси и BGP-подключение. Покрытие HTTP, TCP и UDP определяется выбранной схемой; это разные режимы.
Описание и документация ↗Servicepipe
Web DDoS Protection для сайтов, приложений и API с проксированием. В линейке отдельно описаны защита сети, DNS, WAF и антибот; состав подключённых услуг нужно согласовать.
Описание и документация ↗Yandex Cloud — Smart Web Security
Защита веб-приложений через профиль безопасности: Anti-DDoS, WAF и ограничение нагрузки ARL. Документация предусматривает публикацию доменов приложений как внутри Yandex Cloud, так и во внешней инфраструктуре.
Описание и документация ↗Cloudflare
Сетевые и HTTP-механизмы DDoS-защиты в разных продуктах и конфигурациях. Доступные настройки, протоколы и защита исходного сервера зависят от способа подключения и выбранного сервиса.
Описание и документация ↗В списке есть российские облачные сервисы и зарубежные решения. Доступность, маршруты из сетей ваших пользователей, условия обработки данных и сопровождения проверяют до выбора. Сравнительные испытания этих продуктов здесь не приведены.
Что спросить до подключения
- Что защищается? Домены, IP, DNS, TCP/UDP, API и сервисы, которые остаются вне покрытия.
- Где фильтруется поток? До узкого канала или уже после него; как трафик попадает на платформу.
- Как включается защита? Постоянный режим или переключение по событию, кто его запускает и какие изменения нужны.
- Как проверяют нормальных пользователей? Ошибочные блокировки, CAPTCHA, мобильные клиенты, машинные запросы и интеграции.
- Что входит в условия? Пределы услуги, эскалация, поддержка, отчётность, дополнительные расходы и порядок изменений.
Бюджет зависит от защищаемых ресурсов, протоколов, обычного трафика, выбранных функций, схемы подключения и сопровождения. Рекламная ёмкость сети провайдера сама по себе не описывает условия защиты вашего приложения.
Что делать, если сервис уже недоступен
- 1
Определить масштаб
Какие ресурсы недоступны, с какого времени, что происходит с DNS, каналом и приложением.
- 2
Подключить ответственных
Администратор, владелец сервиса, провайдер связи и действующий поставщик защиты.
- 3
Применить согласованный план
Уточнить вектор и включить подходящую фильтрацию; проверять, что изменения не отрезали обычных клиентов.
- 4
Проверить восстановление
Вход, заказ, оплата, API и другие реальные операции. Сохранить хронологию и причины принятых мер.
Как подготовиться заранее
- 1
Описать критичные ресурсы
Домены, адреса, протоколы и зависимости. Что должно работать во время атаки и какой простой влияет на бизнес.
- 2
Подобрать схему защиты
Веб-прокси для сайта, сетевая очистка для IP-инфраструктуры, защита DNS и дополнительные прикладные проверки.
- 3
Проверить рабочие сценарии
Вход, заказы, API, интеграции 1С, VPN и нужные клиентские приложения. Измерить задержку и долю ошибок.
- 4
Согласовать действия при атаке
Ответственные, контакты провайдера, порядок эскалации, изменения правил и отчёт о доступности после инцидента.
Две памятки для компании
Частые вопросы
DDoS означает, что компанию взломали?
Нет. Недоступность не доказывает проникновение или утечку. Но совпадение DDoS с другими инцидентами требует проверки: журналы, изменения и подозрительные действия анализируют отдельно.
Поможет более мощный сервер?
Запас ресурсов может помочь выдержать часть нагрузки, но не освобождает заполненный внешний канал и не гарантирует устойчивость приложения. Сначала находят ограничивающий участок.
Зачем anti-DDoS, если уже есть NGFW?
NGFW применяет правила и локальные защитные механизмы к дошедшему до него трафику. Если перегрузка возникла у провайдера до шлюза, нужна фильтрация выше по сети. Прикладные запросы тоже требуют своих мер.
Можно просто включить CAPTCHA для всех?
Проверка пользователя подходит не для каждого сервиса: API, интеграция 1С или мобильный клиент могут её не пройти. Важно проверить обычных посетителей и машинные подключения, а не только браузер администратора.
Смена IP-адреса решает проблему?
Иногда это даёт временный эффект, но адрес могут обнаружить снова. Нужно проверить маршруты, DNS, прямой доступ к серверу и условия подключения защиты. Постоянная устойчивость требует согласованной схемы.
Связанные задачи защиты
Подробнее о локальных профилях DoS, WAF и публикации приложений — в статье про NGFW. Защита от DDoS дополняет эти средства, а не заменяет обновления, контроль доступов и резервное копирование.
Разберём, что должно оставаться доступным
Начнём с важных сервисов, каналов связи и последствий простоя. Обсудим схему защиты, взаимодействие с провайдером и критерии проверки результата.
Обсудить защиту сервисов