Пример инцидента (реалистичный кейс)
- Сценарий: злоумышленник объявляет через BGP чужой префикс $203.0.113.0/24$ от имени $AS65099$; трафик к сервису перенаправляется через его сеть и одновременно по этому каналу идёт DDoS-атака объёмом порядка $100\text{Gbps}$. Последствие — пакеты не доходят до легитимных дата‑центров и линк/провайдеры испытывают перегрузку.
Пошаговый алгоритм реагирования (для сетевого инженера + команды безопасности)
1) Быстрая диагностика (0–$..$ первые минуты)
- Подтвердить симптом: мониторинг доступности, метрики RTT/потерь, spike в потоке NetFlow/sFlow.
- Определить аномалию BGP: собрать текущие объявления — команды (пример):
- Cisco: `show ip bgp $203.0.113.0/24$`
- Juniper: `show route receive-protocol bgp $AS65099$`
- Собрать временные метки точного начала аномалии (UTC, синхронизированное NTP).
2) Сбор артефактов (обязательные артефакты для последующего анализа и юр‑процессов)
- BGP: MRT dumps / RIB snapshots / BGP UPDATEs (MRT формат), output команд: `show ip bgp neighbors`, `show bgp ipv4 unicast received-routes` — сохранять в оригинальном виде.
- NetFlow/sFlow/IPFIX экспорт за периоды до/в ходе/после инцидента.
- PCAP с пограничных интерфейсов (при возможности с выборкой SYN/UDP/ICMP).
- Логи маршрутизаторов и ACL (timestamps, конфиг изменения).
- WHOIS / IRR / RPKI ROA (доказательство владения префиксом).
- Переписки с провайдерами (email headers), тикеты поддержки, телефонные записи (фиксация контактов).
- Снимки состояния правил фильтрации и таблиц маршрутизации до и после мер.
3) Немедленная сдерживающая тактика (containment)
- Если DDoS перегружает входящий линк — попросить upstream/провайдеров включить RTBH (Remote Triggered Black Hole) для проблемных префиксов: сообщить префикс $203.0.113.0/24$.
- Для точечной фильтрации запроса FlowSpec (если поддерживается): внедрить правила на границе для блокировки сигнатурного трафика (SYN flood, UDP amplification, Spoofed source).
- Если можно, перенаправить трафик на scrubbing‑центр (DDoS‑mitigation provider) через BGP communities или договорённую сессию: сообщить community для redirection.
- Не применять массовую deaggregation без координации; агрессивная анноттация может усугубить проблему.
4) Локализация BGP‑хаиджа (поиск источника объявления)
- Сравнить AS_PATH, NEXT_HOP, BGP communities, атрибуты анонса.
- Проверить RPKI: если нет ROA, немедленно создать/обновить ROA для префикса; оповестить транзитных провайдеров.
- Проверить фильтры на ближайших peer/IXP — попросить соседей временно применить prefix‑filter, основанный на IRR/ROA.
5) Координация с провайдерами и третьими сторонами
- Контакт-лист: abuse@upstream, NOC, peering contacts, DDoS‑provider, национальный CERT. Отправить краткое сообщение с обязательной информацией:
- Префикс: $203.0.113.0/24$
- Владелец (WHOIS): организация X, ASN $AS65000$
- Время обнаружения (UTC) и MRT/PCAP/NetFlow прикреплённые артефакты
- Просьба: применить RTBH / accept/deny route / направить на scrubbing
- Попросить upstream временно фильтровать анонсы со стороны $AS65099$ и/или прекратить принятие маршрутов с некорректным origin.
6) Точки фильтрации и настройки (технические опции)
- RTBH (черный ход) на уровне провайдера для префикса $203.0.113.0/24$.
- BGP FlowSpec правила для блокировки специфичных типов трафика (TCP flags, UDP ports, packet length).
- Уровневые ACL/iptables на краю сети для сигнатурных фильтров; при этом минимизировать impact на legitimate traffic.
- uRPF/Reverse Path для уменьшения spoofing‑трафика (включать осторожно, тестировать).
- Rate‑limiting и connection‑tracking на сервисном уровне (limiting SYN queue, SYN cookies).
- В долгосрочной перспективе: RPKI/ROA, строгие prefix‑filters на peering и transit, MD5/TCP-AO для iBGP/EBGP по возможности, BGP session protection (TTL security, prefix‑limits).
7) Юридические и процедурные шаги
- Сохранить цепочку владения доказательствами (chain of custody): кто собрал, когда, где хранится. Подписывать/хешировать артефакты (например SHA256).
- Немедленно уведомить внутренний юрист/комплаенс; при необходимости — местный CERT/CSIRT и правоохранительные органы.
- Подготовить пакет для провайдеров и для правоохранительных органов: WHOIS, ROA, MRT, PCAP, NetFlow, время и потенциальный ущерб.
- Учитывать требования по защите персональных данных (GDPR и пр.) при передаче логов — минимизировать персональные данные, использовать защищённые каналы.
- Сохранять логи согласно нормативам (обычно минимум $90$ дней, уточнить в политике и по требованию юриста).
8) Коммуникация и координация внутри команды
- Назначить единого координатора инцидента (incident lead) и контакт‑лицо для провайдеров.
- Вести журнал действий (what/when/who), фиксировать все изменения конфигураций и команды rollback.
- Публичные коммуникации (клиенты/партнёры): согласовать с PR/Legal сообщение и тайминг; не раскрывать технические детали, которые помогут злоумышленнику.
9) Анализ после инцидента и меры на будущее
- Провести пост‑мортем: root cause (как был выполнен хайдж), почему фильтры не сработали.
- Внедрить долгосрочные защиты: RPKI ROA, строгие filter‑lists по peering, договоренности с DDoS‑поставщиками на pre‑filtering, BGP monitoring (BGPmon/RIPE RIS/RouteViews, alerts).
- Обновить runbook, добавить контакты провайдеров, отработать tabletop exercise; при необходимости юридические/регуляторные отчёты.
Краткий чек‑лист для немедленных действий (под руками)
- Собрать MRT/RIB, NetFlow, PCAP — сохранить оригиналы.
- Связаться с upstream NOC с префиксом $203.0.113.0/24$, приложить артефакты.
- Включить RTBH / FlowSpec / перенаправление на scrubbing.
- Уведомить CERT и внутреннего юриста, сохранить chain of custody.
Если нужно — могу прислать шаблон письма для провайдера/abuse, список команд для Cisco/Juniper для экспорта MRT и примеры FlowSpec‑правил.