Кейс: как мы отразили DDoS-атаку на финтех-компанию

Пятница, 22:45. Типичное время для начала серьезных проблем в IT. Системы мониторинга фиксируют резкий аномальный скачок входящего трафика на шлюзах платежного процессинга — украинской финтех-компании. За 40 секунд объем паразитных запросов вырастает с привычных 800 Mbps до критических 450 Gbps, продолжая стремительно набирать обороты. Попытка открыть клиентское приложение приводит к классическому таймауту, а нагрузка на балансировщики взлетает до 100%.

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

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

Исходные данные: архитектура клиента до инцидента

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

Технический стек и топология сети

• Облачный провайдер: Гибридное решение на базе Microsoft Azure (основные вычислительные мощности) и выделенных bare-metal серверов в дата-центрах Франкфурта и Варшавы для соблюдения требований PCI DSS.
• Входная точка (Edge): Azure Front Door и стандартный балансировщик нагрузки L4.
• Оркестрация: Кубернетес-кластеры (AKS) с микросервисной архитектурой.
• Базы данных: Azure SQL Managed Instance и кластер Redis для кэширования транзакционных сессий.

Уязвимые места в исходной конфигурации

Аудит, проведенный сразу после начала инцидента, выявил несколько критических недочетов в базовой архитектуре:

1. Отсутствие глубокой фильтрации на уровне L7: Web Application Firewall (WAF) работал в режиме мониторинга («Detection Only») из-за опасений команды клиента заблокировать легитимный платежный трафик с необычными заголовками от терминалов партнеров.
2. Статичный Rate Limiting: Пороги ограничения количества запросов были настроены глобально, а не поведенчески, что позволило распределенному ботнету легко обходить лимиты, имитируя обычных пользователей.
3. Уязвимость API-эндпоинтов: Ресурсоемкие методы (например, генерация сложных финансовых выписок и поиск по архивным транзакциям) не имели жесткой изоляции по очередям обработки.

Хронология атаки: 4 часа борьбы за доступность

Инцидент развивался волнообразно. Злоумышленники использовали классическую тактику: сначала нанесли массированный удар по сетевому уровню, чтобы «ослепить» мониторинг, а затем перешли к прицельным интеллектуальным атакам на прикладной уровень.

Технический разбор: как работала защита сервера и сети на каждом уровне

Отражение атаки такого масштаба требует не одной «волшебной кнопки», а эшелонированной обороны (Defense-in-Depth). Рассмотрим, какие конкретно действия предпринимала наша инжиниринговая команда на каждом этапе.

1. Нивелирование объемных атак (L3/L4 Network Layer)

Первый удар SYN Flood и UDP-амплификации грозил «положить» аплинки дата-центров.

Наши действия:

• Люнг-маршрутизация (BGP Anycast): Мы оперативно анонсировали префиксы клиента через глобальную сеть скраббинговых центров (очистки трафика). Трафик был распределен по 20+ точкам присутствия (PoP) по всему миру, что снизило нагрузку на европейские узлы.
• Жёсткий дроп UDP: Поскольку API финтех-приложения работает строго по протоколу TCP/HTTPS, весь входящий UDP-трафик на внешних границах был полностью заблокирован на уровне BGP Flowspec.
• Синтетические SYN-куки (SYN Cookies): На аппаратных файрволах была активирована генерация SYN-кук. Сервер перестает выделять память под полуоткрытые соединения до тех пор, пока клиент не подтвердит получение пакета (ACK). Это мгновенно снизило нагрузку на CPU edge-серверов с 98% до адекватных 45%.

2. Отражение атак на прикладном уровне (L7 Application Layer)

Самой сложной частью стала Фаза 3. Злоумышленники задействовали уязвимость HTTP/2 Rapid Reset (когда клиент массово отправляет фреймы HEADERS, создавая потоки, и тут же сбрасывает их через RST_STREAM). Стандартные балансировщики буквально захлебывались от необходимости обрабатывать миллионы обрядов рукопожатия TLS и парсинга заголовков.

Реализованный пайплайн фильтрации:

[Входящий трафик 1.2 Tbps]
       │
       ▼
┌──────────────────────────────────────────────┐
│ 1. BGP Anycast & Edge Scrubbing (Сброс L3/L4)│
└──────────────────────┬───────────────────────┘
                       │ (Очищенный TCP трафик ~15 Gbps)
                       ▼
┌──────────────────────────────────────────────┐
│ 2. TLS/SSL Offloading & Fingerprinting (JA3) │
└──────────────────────┬───────────────────────┘
                       │ (Отсечение простейших скриптов)
                       ▼
┌──────────────────────────────────────────────┐
│ 3. WAF & поведенческий анализ (Cloudflare/Custom)
└──────────────────────┬───────────────────────┘
                       │ (Только валидные HTTPS запросы ~1.2 Gbps)
                       ▼
┌──────────────────────────────────────────────┐
│ 4. Kubernetes Ingress (Rate Limiting по JWT) │
└──────────────────────────────────────────────┘

Настройка TLS Fingerprinting (JA3/JA4)

Боты могут подделывать User-Agent, копируя Chrome или Safari на iOS, но они редко могут корректно эмулировать особенности реализации TLS-стека браузера. Мы внедрили фильтрацию по отпечаткам JA3:

• Собрали эталонные JA3-хеши легитимных мобильных приложений клиента (iOS/Android) и популярных браузеров.
• Все запросы с несовпадающими отпечатками (например, дефолтные библиотеки Python Requests, Go HTTP client или кастомные C++ скраперы) мгновенно отправлялись на JavaScript-челлендж или сбрасывались (Drop).

Динамический Rate Limiting по поведенческим паттернам

Вместо ограничения по IP-адресу (которое бесполезно против резиденциальных прокси), мы перевели WAF на лимитирование по сессионным метрикам:

• Ограничение на создание новых TLS-сессий с одного IP: не более 5 в секунду.
• Лимитирование обращений к эндпоинту /api/v2/auth — не более 3 запросов в минуту с одного устройства (на основе fingerprint).
• Включение проверки целостности браузера (Managed Challenge) для всех неопознанных сессий. Легитимный пользователь проходит проверку за 50 мс в фоне, бот на Node.js или curl — отваливается.

Итоги инцидента и ключевые метрики

Благодаря слаженным действиям команды и автоматизации систем защиты, критическая фаза недоступности сервиса длилась всего 14 минут (во время первой волны перенастройки BGP). Остальные 3.5 часа атаки система отработала в штатном режиме с минимальной деградацией скорости ответа API (latency выросло всего на 40 мс).

Впечатляющие цифры кейса:

• 1.2 Tbps / 4.5 млн RPS — пиковая мощность зафиксированной атаки.
• 99.98% — итоговый SLA доступности платежного шлюза за месяц инцидента.
• 0 потерянных транзакций — благодаря изоляции очередей базы данных ни одна финансовая операция не была повреждена.
• $0 — переплата за трафик в облаке (за счет фиксации тарифов на скраббинг-сервисах на уровне Edge).

Чек-лист для CTO: безопасность сервера и инфраструктуры от DDoS

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

• [ ] Разделение плоскостей трафика. Никогда не светите реальные IP-адреса балансировщиков или origin-серверов. Используйте CDN или скраббинг-центры в режиме прокси.
• [ ] Проверка таймаутов на всех уровнях. Убедитесь, что таймауты Keep-Alive на Nginx/Ingress настроены жестко (например, 5–10 секунд). Долгоживущие простаивающие соединения — лучшая мишень для атак типа Slowloris.
• [ ] Включение кэширования агрессивных запросов. Статические данные и тяжелые GET-запросы без авторизации должны отдаваться прямо с Edge-серверов или CDN, не доходя до бэкенда.
• [ ] Аудит ресурсоемких эндпоинтов. Составьте список самых тяжелых для БД запросов в вашем API. Именно их будут атаковать в первую очередь при L7-флуде. Настройте для них строгие отдельные лимиты (Rate Limiting).
• [ ] Проведение Chaos Engineering тестов. Не ждите реальной атаки. Проводите регулярные контролируемые стресс-тесты (Red Teaming) с имитацией мультивекторных атак на вашу инфраструктуру.

FAQ: Часто задаваемые вопросы о защите от DDoS

1. Можно ли защитить сервер только силами стандартного фаервола (например, iptables или ufw)?

Нет, на современном уровне угроз это невозможно. Стандартный программный фаервол работает за счет ресурсов CPU вашего же сервера. Если на сервер прилетит атака даже в 10–20 Gbps (а тем более 1.0+ Tbps), сетевой интерфейс или ядро Linux просто захлебнутся при обработке прерываний (IRQ Flood), и сервер перестанет отвечать, даже если фаервол сбрасывает все пакеты. Фильтрация объема должна происходить до того, как трафик попадет в ваш дата-центр.

2. Чем отличается защита от DDoS для финтеха от обычного E-commerce?

В финтехе критически важна минимальная задержка (latency) при проведении транзакций и абсолютная сохранность сессионных данных. Мы не можем просто включить агрессивную CAPTCHA для всех пользователей, так как это сломает автоматические межсерверные интеграции (M2M) и платежные терминалы. Защита должна строиться на точной поведенческой аналитике, проверке валидности криптографических подписей и TLS-отпечатков без ухудшения пользовательского опыта.

3. Почему облачные провайдеры (AWS/Azure) не защищают от атак L7 «из коробки»?

Базовая защита облачных гигантов (например, AWS Shield Standard или Azure Basic DDoS) отлично справляется с сетевыми атаками L3/L4. Однако на уровне L7 (HTTP/HTTPS) паразитный трафик выглядит как абсолютно легитимные обращения пользователей. Чтобы отделить бота от покупателя, необходима тонкая настройка WAF, знание логики конкретно вашего приложения и постоянное профилирование трафика, что реализуется только через расширенные платные сервисы или привлечение профильных DevSecOps команд.

4. Сколько стоит построение надежной защиты для среднего бизнеса?

Инвестиции делятся на две части: инфраструктура (подписка на Enterprise WAF / Anycast сети, от $500 до $3000+ в месяц в зависимости от объема легитимного трафика) и инженерные часы на правильное проектирование отказоустойчивой архитектуры. При этом стоимость защиты всегда кратно ниже ущерба от одного дня простоя успешного бизнеса.

Заключение

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

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

Пора проверить вашу инфраструктуру на прочность! Свяжитесь с нашими архитекторами для проведения комплексного аудита сетевой безопасности и нагрузочного тестирования. Мы поможем выявить узкие места, настроим эшелонированную защиту и обеспечим бесперебойную работу вашего бизнеса 24/7/365.