Защита от объёмных DDoS-атак в дипломе: от рекорда 12 Тбит/с к измеримому результату

25 марта 2026 года SecurityLab выпустил материал с заголовком «12 терабит ярости. Рекорды, которые мы заслужили (но совсем не хотели)». Суть в двух строках: пароли больше никого не волнуют — злоумышленников интересует объём трафика. Это не курьёз из ленты новостей, а смена парадигмы. Пока одни студенты в третьей главе ВКР рассказывают про сложность пароля и капчу, атака измеряется в терабитах в секунду и укладывает канал оператора связи.

Для выпускника ИТ-направления такая новость — подарок. Она мгновенно даёт актуальность, конкретную задачу, набор метрик и понятный критерий успеха. Ниже — как встроить этот сюжет в ВКР так, чтобы комиссия увидела инженерную работу, а не реферат по безопасности.

Что рекорд 12 Тбит/с означает на языке архитектуры

Объём атаки — это не «скорость взлома», а суммарный поток, который нужно куда-то деть. Пока он идёт, полезные запросы не доходят до сервиса. Отсюда три независимых фронта работ: где мы перехватываем поток, как отличаем атаку от легитимного пика и что делаем, когда фильтр не справляется. Именно эти три вопроса и разворачиваются в главы диплома.

Такая классификация — отличный каркас для первого параграфа аналитической главы. Она опирается на официальную таксономию MITRE ATT&CK (техника T1498, Network Denial of Service), а значит, ссылку на источник можно поставить без риска получить вопрос «а откуда цифры?».

Три темы ВКР, которые вырастают из этой новости

1. Проектирование подсистемы защиты веб-сервиса от объёмных атак на базе anycast и scrubbing-центра

Актуальность: в материале SecurityLab речь идёт о рекордных объёмах, которые не «переваривает» одиночная площадка. Значит, защита обязана быть распределённой.

Цель: разработать архитектуру подсистемы, распределяющей и очищающей входящий трафик, и подтвердить её работоспособность на стенде.

• Проанализировать классы атак и существующие решения по критериям ISO/IEC 25010.
• Спроектировать схему anycast-анонсирования и правила фильтрации на границе.
• Собрать прототип на стенде и снять метрики до/после включения фильтра.
• Оценить стоимость владения и сравнить с арендой облачной защиты.

Структура: Глава 1 — анализ угроз, обзор рынка, обоснование стека. Глава 2 — архитектура (контекстная и компонентная схемы, ТЗ по ГОСТ 34.602-89, спецификация фильтров). Глава 3 — стенд, сценарии испытаний, расчёт экономики.

2. Автоматизация реагирования на инциденты доступности: оркестрация BGP-анонсов и тонкая фильтрация в Kubernetes

Актуальность: при терабитных потоках человек физически не успевает реагировать руками. Разрыв между «заметили» и «отфильтровали» — это часы простоя. Новость прямо подсказывает: выигрывает тот, у кого реакция автоматическая.

Цель: сократить среднее время реагирования (MTTR) на инцидент доступности за счёт автоматической оркестрации политик фильтрации.

• Разобрать жизненный цикл инцидента по NIST SP 800-61 и зафиксировать точки автоматизации.
• Спроектировать контроллер, который по сигналу от мониторинга применяет BGP-анонс и правила фильтрации.
• Реализовать прототип: Custom Resource в Kubernetes + обработчик событий Alertmanager.
• Сравнить ручной и автоматический сценарий по MTTR и числу ошибок оператора.

Структура: Глава 1 — теория реагирования и протоколы маршрутизации. Глава 2 — проектирование контроллера, диаграммы последовательностей и состояний. Глава 3 — прогон сценариев инцидентов, метрики, инструкция по эксплуатации.

3. Сравнительная оценка методов фильтрации L4/L7: доступность, качество обслуживания, стоимость

Актуальность: рекорд объёма обнуляет часть «классических» рекомендаций из методичек. Нужна методика, которая честно говорит, где работает облачный scrubbing, а где — локальный rate limiting.

Цель: разработать методику сравнительной оценки методов защиты и применить её к 3–4 конфигурациям.

• Отобрать метрики по группам «производительность», «надёжность», «безопасность» из ISO/IEC 25010.
• Построить модель стоимости: собственный стенд против облачного тарифа.
• Провести серию экспериментов с разными профилями нагрузки.
• Сформулировать рекомендации по выбору метода для разных типов сервисов.

Структура: Глава 1 — стандарты качества и метрики. Глава 2 — методика и инструментарий. Глава 3 — эксперименты, расчёты, выводы и ограничения применимости.

Аналитическая глава: как обосновать стек, а не перечислить модные слова

Слабое место большинства ВКР — список технологий без критериев. Комиссия это чувствует за минуту. Помогает один приём: каждое решение описывается через отброшенные альтернативы и цену выбора.

Такой таблицы достаточно, чтобы закрыть вопрос «почему вы выбрали именно это». Дальше — обоснование инструментов наблюдения: Prometheus и Grafana для метрик, OpenTelemetry для сквозной трассировки, GitLab CI для сборки и развёртывания стенда. Каждый инструмент привязывается к конкретной задаче главы, а не к общему списку «современных технологий».

Проектная часть: схемы, алгоритмы, интеграция

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

Практический фрагмент конфигурации, который уместно привести во второй главе как иллюстрацию прикладного уровня защиты:

limit_req_zone  $binary_remote_addr zone=api:10m rate=20r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    listen 443 ssl;
    limit_req  zone=api burst=40 nodelay;
    limit_conn conn 30;
    limit_req_status 429;
    limit_conn_status 429;
}

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

Тестирование и метрики: где рождаются цифры для защиты

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

Что имеет смысл измерять:

Пример запроса для расчёта доли ошибок — пригодится как иллюстрация в третьей главе:

sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
sum(rate(http_requests_total[5m]))

Отдельным подпунктом стоит блок «что делать, если метрика деградировала». Это уже не тестирование, а управление рисками: сценарии деградации, пороги алертов, порядок эскалации. Тут же уместно упомянуть RTO и RPO — их значения берутся из требований заказчика, а не назначаются «на глаз».

Чему вы научитесь, пока пишете эту работу

• Разбирать инцидент доступности на уровни и выбирать средство защиты под каждый уровень, а не «ставим WAF и надеемся».
• Строить схему распределения трафика и объяснять, почему anycast выигрывает у одного дата-центра.
• Настраивать мониторинг так, чтобы алерт приходил до звонка пользователей, а не после.
• Считать экономику решения: стоимость отражения атаки в час против стоимости простоя.
• Оформлять ТЗ и документы АС в соответствии с ГОСТ 34.602-89 и ГОСТ Р 59795-2021, а не в свободной форме.
• Доказывать выбор инструментов через критерии качества по ISO/IEC 25010, а не через популярность технологии.

Частые вопросы студентов

Источник: 12 терабит ярости. Рекорды, которые мы заслужили (но совсем не хотели) (опубликовано 2026-03-25)