П’ятниця, 22:45. Типовий час для початку серйозних проблем в IT. Системи моніторингу фіксують різкий аномальний стрибок вхідного трафіку на шлюзах платіжного процесингу — української фінтех-компанії. За 40 секунд обсяг паразитних запитів зростає з звичних 800 Mbps до критичних 450 Gbps, продовжуючи стрімко набирати оберти. Спроба відкрити клієнтський застосунок призводить до класичного таймауту, а навантаження на балансувальники злітає до 100%.
Для фінансового сектору кожна хвилина недоступності сервісу — це прямі збитки в десятки тисяч доларів, зрив транзакцій, а головне — непоправний удар по репутації бренду. У цій статті ми детально розберемо наш захист від DDoS кейс, покажемо виворіт протистояння з сучасними ботнетами і розповімо, как грамотна безпека сервера та хмарної інфраструктури дозволила зберегти працездатність ядра системи під час атаки потужністю понад 1.2 Tbps.
Цей матеріал не про базові налаштування фаєрвола. Ми поділимося конкретними архітектурними рішеннями, метриками та пайплайнами фільтрації, які будуть корисні CTO, технічним лідам та архітекторам високонавантажених систем.
Вихідні дані: архітектура клієнта до інциденту
Перед тим як розбирати саму атаку, важливо розуміти ландшафт інфраструктури проєкту. Наш клієнт надає API для проведення платежів і обслуговує понад 1.5 мільйона активних користувачів.
Технічний стек та топологія мережі
- Хмарний провайдер: Гібридне рішення на базі Microsoft Azure (основні обчислювальні потужності) та виділених bare-metal серверів у дата-центрах Франкфурта та Варшави для дотримання вимог PCI DSS.
- Вхідна точка (Edge): Azure Front Door та стандартний балансувальник навантаження L4.
- Оркестрація: Кубернетес-кластери (AKS) з мікросервісною архітектурою.
- Бази даних: Azure SQL Managed Instance та кластер Redis для кешування транзакційних сесій.
Уразливі місця у вихідній конфігурації
Аудит, проведений одразу після початку інциденту, виявив кілька критичних недоліків у базовій архітектурі:
- Відсутність глибокої фільтрації на рівні L7: Web Application Firewall (WAF) працював у режимі моніторингу («Detection Only») через побоювання команди клієнта заблокувати легітимний платіжний трафік із незвичними заголовками від терміналів партнерів.
- Статичний Rate Limiting: Пороги обмеження кількості запитів були налаштовані глобально, а не поведінково, що дозволило розподіленому ботнету легко обходити ліміти, імітуючи звичайних користувачів.
- Уразливість API-ендпоінтів: Ресурсомісткі методи (наприклад, генерація складних фінансових виписок та пошук за архівними транзакціями) не мали жорсткої ізоляції за чергами обробки.
Хронологія атаки: 4 години боротьби за доступність
Інцидент розвивався хвилеподібно. Зловмисники використовували класичну тактику: спочатку завдали масованого удару по мережевому рівню, щоб «осліпити» моніторинг, а потім перейшли до прицільних інтелектуальних атак на прикладний рівень.
| Етап / Час | Вектор атаки | Пікова потужність | Характер впливу та ціль |
| Фаза 1 (00:00 – 00:25) | Volumetric (SYN Flood + UDP Amplification) | 450 Gbps / 60 Mpps | Вичерпання пропускної здатності каналів зв’язку та переповнення таблиць станів балансувальників. |
| Фаза 2 (00:25 – 01:40) | Protocol Attack (TCP ACK/FIN Flood + Smurf) | 850 Gbps / 110 Mpps | Виснаження ресурсів мережевих стеків edge-маршрутизаторів та серверів достуу. |
| Фаза 3 (01:40 – 03:15) | Application Layer (HTTP/2 Rapid Reset + Slowloris) | 1.2 Tbps / 4.5 M RPS | Точкові удари по важких ендпоінтах API для вичерпання пулів потоків у Node.js та .NET сервісах. |
| Фаза 4 (03:15 – 04:00) | Змішаний (Smart Botnet Emulation) | ~300 Gbps / 1.8 M RPS | Спроба обходу увімкнених правил фільтрації з використанням реальних мобільних IP (residential proxies). |
Технічний розбір: як працював захист сервера та мережі на кожному рівні
Відбиття атаки такого масштабу вимагає не однієї «чарівної кнопки», а ешелонованої оборони (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.