Защита от DDoS: практическое руководство

DDoS (Distributed Denial-of-Service) остаётся одной из самых распространённых форм атак на сетевые и веб-сервисы. Они не всегда преследуют цель прямого кражи данных — часто злоумышленники стремятся вывести сервис из строя, шантажировать, отвлечь внимание для дальнейших атак или протестировать возможности инфраструктуры перед более целенаправленными действиями.

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

Что такое DoS и DDoS

Определение в одну строку: DoS — одиночная попытка исчерпать ресурсы сервера или сети; DDoS — та же цель, но атака идёт с множества узлов одновременно.

Коротко о механике:

• DoS: одна машина или узел отправляет слишком много запросов, использует уязвимость или создает нагрузку, которую жертва не может обработать.
• DDoS: ботнеты (сети заражённых устройств) направляют трафик одновременно с разных IP, что затрудняет блокировку по одному адресу.

Типичные техники и приёмы:

• Потоковый наплыв (volumetric) — переполнение пропускной способности канала (UDP/ICMP фрагменты, отражённые DNS/NTTP/CLDAP усиления).
• Протокольные атаки — исчерпание состояний (SYN-flood, TCP state exhaustion).
• Атаки на приложение — перегрузка HTTP/HTTPS, сложные запущенные запросы, специфичные для приложения вызовы.

Особенности отражённых атак: злоумышленник шлёт запросы с подделанным IP жертвы к множеству рефлекторов (например, открытые DNS), которые отвечают на поддельный адрес, тем самым усиливая объём трафика. Это усложняет атрибуцию.

Почему IoT опасны: устройства Интернета вещей часто используют простые пароли и редкие обновления, поэтому их легче захватить и включить в ботнет. Некоторые ботнеты продаются как услуга (DDoS-for-hire).

Что делать до атаки

Подготовка — это то, что даст вам преимущество и сократит время простоя.

Важно: планируйте исходя из критичности сервиса — сервисы с высоким уровнем доступности требуют более жёстких мер и запасных каналов.

Оцените поверхность атаки

• Составьте инвентаризацию публичных сервисов (HTTP(S), API, почтовые шлюзы, VPN, RTP, игровые серверы и т.д.).
• Для каждого сервиса укажите: публичный IP, порт, протокол, критичность, допустимые окна простоя.
• Определите зависимости между сервисами (DNS, аутентификация, базы данных).

Быстрые укрепления

• Включите и проверьте Web Application Firewall (WAF): убедитесь, что правила покрывают публичные приложения и API. Добавьте правило тонкой фильтрации по поведению API (rate-limiting, проверка джсон-схемы).
• Примените базовые правила защиты на сетевом уровне: SYN cookies, корректные параметры TCP/IP (ratelimit на новые соединения), anti-spoofing (uRPF) на пограничных маршрутизаторах.
• Закройте ненужные публичные порты; перенесите админ-интерфейсы в приватные сети или доступ через VPN/Zero Trust.
• Разделите управление и рабочую нагрузку: консоль управления и службы оркестрации не должны быть публичными.

Работайте с провайдерами

• Согласуйте SLA и возможности реагирования с ISP и CSP. Узнайте, предлагают ли они scrubbing-сервисы, Anycast-доступ или BGP blackholing.
• Иметь договоры и контакты (24/7) для быстрого включения поддержки.
• Рассмотрите сторонние DDoS-скраббинговые сервисы и CDN с анти-DDoS функциями.

Архитектура для живучести

• Используйте Anycast/мульти-региональные развёртывания, чтобы распределять нагрузку и снижать влияние на одну точку.
• Лимитируйте сессии: rate-limiting на уровне edge/CDN; отдельные rate-limits для API и для статического контента.
• Настройте Health Checks и автоматическое масштабирование, но имейте план на случай, если масштабирование не поможет поглотить вредоносный трафик.

План реагирования и учения

• Составьте DDoS Response Plan: роли, коммуникации, шаги эскалации, контакты провайдеров, чек-листы по каждому сценарию.
• Проводите tabletop-упражнения и симуляции (имитация нагрузки в контролируемой среде).
• Определите критерии перехода в режим полной защиты (например, когда latency > X или процент недоступных запросов > Y).

Мини-методология подготовки (чек-лист)

1. Инвентаризация публичных сервисов.
2. Проверка и тест WAF/IDS/IPS.
3. Договоры с ISP/CSP и контакты экстренной связи.
4. Тестирование резервных маршрутов и Anycast.
5. Регулярные учения и обновление плана.

Что делать во время атаки

Во время инцидента приоритеты: обнаружить, ограничить ущерб, сохранить критичные сервисы, документировать.

Признаки атаки

• Резкое увеличение входящего трафика, часто из множества географий.
• Увеличение ошибок 5xx на прикладном уровне.
• Высокая загрузка CPU/памяти на пограничных устройствах и веб-серверах.
• Нестабильность сети: потеря пакетов, увеличенные задержки.

Шаги реагирования (пошагово)

1. Активация инцидентного плана и уведомление команды DDoS-реагирования.
2. Связь с ISP/CSP: выяснить, наблюдают ли они аномалию и готовы ли применять фильтрацию на своей границе.
3. Начать сбор доказательств: включить логирование, захватить PCAP на пограничных интерфейсах и на сервере. PCAP помогает понять тип трафика и признаки отражённой атаки.
4. Идентифицировать целевые IP/порты и характер запросов (volumetric, SYN-flood, HTTP-flood).
5. Включить автоматические mitigations (rate-limiting, connection-limits, SYN cookies) и применить временные блокировки / ACL на уровне edge.
6. При необходимости — перенаправление трафика на scrubbing-центр или активация CDN/Anycast.
7. Ограничьте влияние на критичные связи: приоритизируйте трафик для бизнес-критичных сервисов.
8. Постоянно мониторьте параметры: трафик, логи, метрики приложения и пользовательские метрики.
9. Ведите журнал действий (кто и когда сделал что) — это важно для последующего разбора и возможных юридических действий.

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

Технические приёмы смягчения

• BGP blackholing — использование провайдера для отбрасывания трафика на границе. Подходит для атак, направленных на IP, где потеря доступности лучше, чем перегрузка всей сети.
• BGP Flowspec — более тонкая фильтрация на уровне маршрутизаторов провайдера.
• Scrubbing-сервисы — отправка трафика через специализированные центры очистки, где вредоносный трафик отфильтруют.
• Rate-limiting и connection limiting — ограничение новых соединений и общего throughput.
• Geo/ASN блокировки — если атака идёт из определённых регионов или AS.
• CAPTCHA/Challenge для снижения нагрузки на приложение.
• Offloading статического контента на CDN.

Практические команды и сниппеты

Пример iptables-правила для ограничения новых соединений (Linux):

# ограничение новых TCP соединений до 20 в минуту (пример)
iptables -A INPUT -p tcp --syn -m limit --limit 20/min --limit-burst 40 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Пример nginx: простая лимитация по IP для API

http {
  limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

  server {
    location /api/ {
      limit_req zone=api burst=20 nodelay;
      proxy_pass http://backend;
    }
  }
}

Wireshark/PCAP советы:

• Фильтры: ip.addr == <жертва> && (tcp || udp) для фокусировки на входящем трафике.
• Ищите повторяющиеся patterns, одинаковые payload, единый user-agent или подписи ботнета.
• Анализ распределения источников (по IP/ASN/гео) — помогает выбрать блокировки.

Роль коммуникации

• Обеспечьте единый канал связи для команды реагирования.
• Уведомьте ключевых стейкхолдеров (директора, связь с клиентами, PR) по заранее подготовленному шаблону.
• Поддерживайте клиентов: публикуйте status page с обновлениями (важно избегать паники и неверной информации).

Что делать после атаки

После окончания атаковой волны приоритеты — восстановление, разбор и улучшение защиты.

Немедленные действия

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

Пост-мортем и обновление планов

• Проведите ретроспективу (post-mortem): что произошло, какие меры сработали, какие нет, сколько времени ушло на реагирование.
• Обновите DDoS Response Plan: включите новые уроки, уточните контакты и пороговые значения мониторинга.
• Регулярно тестируйте изменения: прогоняйте контрольные симуляции и проверяйте, что WAF/IDS корректно реагируют.

Технические улучшения

• Уточните и расширьте правила WAF, rate-limits и ACL на пограничных устройствах.
• Настройте проактивное оповещение по отклонениям от базовой линии трафика.
• Внедрите или обновите CDN/Anycast и интеграцию со скраббинг-провайдером.

Юридические и регуляторные аспекты

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

Продвинутые подходы и когда они не сработают

Контрмеры имеют свои ограничения. Приведённые ниже пункты помогут понять, в каких сценариях стандартные подходы могут провалиться.

Когда защитные меры дают слабый эффект:

• Атака использует большое разнообразие источников (широкий спектр IP/ASN/гео), что усложняет фильтрацию без трёпения легитимного трафика.
• Нагрузочная волна значительно превосходит вашу пропускную способность и возможности провайдера/скраббера.
• Атака направлена на прикладной уровень (slowloris, сложные запросы), где масштабирование не помогает.

Альтернативные подходы при неэффективности обычной защиты:

• Прямое сотрудничество с одним или несколькими провайдерами для дополнительного capacity/скраббинга.
• Временное отключение атакуемого публичного сервиса и переключение клиентов на degraded-режим или зеркало.
• Применение Challenge-Response (CAPTCHA, JavaScript challenges) для снижения автоматизированного трафика.

Модель затрат и компромиссов:

• Поглощение атаки (scale up) обычно дорого и может не помочь при отражённых атаках.
• Фильтрация в провайдерской сети или через скраббер — эффективна, но требует контрактов и выноса трафика.
• Частичная блокировка (geo/ASN) снижает трафик, но может повлиять на легитимных пользователей.

Мини-методология: тестирование и приёмочные критерии

Тестируйте защиту регулярно и по заранее определённым критериям.

Критерии приёмки (пример):

• Сервис остаётся доступен для 95% легитимных запросов при нагрузке X, заданной тестом.
• Время отклика API не увеличивается более чем на 3× относительно базовой линии при пиковом легитимном трафике.
• Механизмы автоматической фильтрации срабатывают и не блокируют более 1% легитимных пользователей.

Тестовые кейсы:

1. Volumetric test: симуляция большого числа UDP/ICMP пакетов с разных источников; проверка реакции провайдера и WAF.
2. Application flood: инструментальное воспроизведение большого числа HTTP POST/GET с валидными и некорректными payload; проверка WAF.
3. State exhaustion: симуляция SYN flood и проверка параметров TCP (SYN cookies).
4. False-positive test: проверка, что блокировки не мешают реальным пользователям (регресс-тесты).

Чек-листы по ролям

Операции сети:

• Убедиться, что BGP-сессии стабильны и есть план blackholing.
• Активировать и мониторить uRPF, SYN cookies, rate-limits.
• Собирать PCAP и сохранять метаданные.

Команда приложений / DevOps:

• Проверить логи приложений на 5xx ошибки.
• Включить rate-limits на уровне reverse-proxy/NLB.
• Переключить не критичные сервисы в режим read-only, если нужно.

Команда связи / PR:

• Подготовить шаблон сообщение для status page и соцсетей.
• Обеспечить регулярные обновления для клиентов и партнёров.

Юридический отдел / Compliance:

• Подготовить уведомления для регуляторов (если требуется).
• Сохранить цепочку доказательств и логи для возможного расследования.

Инцидентный план (runbook) — быстрый набор действий

1. Детектирование
   • Получено оповещение от мониторинга или жалоба пользователей.
   • Включить инцидентную группу.
2. Первичная классификация
   • Оценить природу трафика (volumetric/protocol/app).
   • Зафиксировать метрики и начать сбор PCAP.
3. Связь с провайдером
   • Передать данные и запросить ограничение/скраббинг/Flowspec.
4. Применение локальных мер
   • WAF rules, rate-limits, ACL, CAPTCHAs.
5. Мониторинг и корректировка
   • Проверять влияние мер на легитимный трафик.
6. Пост-инцидент
   • Сохранить все артефакты, провести post-mortem и обновить план.

Критерии отката:

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

Decision tree: как быстро принять решение

flowchart TD
  A[Обнаружено аномальное увеличение трафика] --> B{Происходит потеря доступности?}
  B -- Нет --> C[Усиленный мониторинг и сбор логов]
  B -- Да --> D{Трафик направлен на один IP/порт?}
  D -- Да --> E[Запросить у ISP blackholing / ACL]
  D -- Нет --> F{Тип трафика: volumetric или application?}
  F -- Volumetric --> G[Перенаправление на scrubbing / CDN / Anycast]
  F -- Application --> H[Активация WAF, rate-limits, challenge]
  G --> I[Мониторинг эффективности]
  H --> I
  I --> J[Если не помогает — эскалация к провайдеру и PR]

Глоссарий в одну строку

• DDoS — распределённая атака, направленная на отказ в обслуживании.
• Botnet — сеть заражённых устройств, используемых для атак.
• Scrubbing — очистка трафика в специализированном центре.
• Anycast — маршрутизация одинакового IP в несколько географических точек.
• BGP blackholing — отбрасывание трафика к IP на уровне маршрутизаторов.

Заключение

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

Важно: журналируйте и сохраняйте доказательства — они пригодятся для анализа и возможных юридических действий.

Краткий план действий прямо сейчас:

1. Проведите инвентаризацию публичных сервисов.
2. Проверьте WAF и базовые сетевые настройки (SYN cookies, uRPF).
3. Согласуйте контакты и возможности с ISP/CSP.
4. Подготовьте и отработайте простой runbook для команды.