Уроки масштабної DDoS-атаки на квитковий сервіс: розбір від Артема Атаманчука

Автор: Василь Мельник

Навесні 2018 року український квитковий сервіс Karabas.com пережив найпотужнішу DDoS-атаку в своїй історії: сервіс отримував мільйон запитів на секунду впродовж двох місяців.

Редакція Бізнес Цензор запросила Senior DevOps-інженера Артема Атаманчука, фахівця з 7-річним досвідом захисту високонавантажених систем, проаналізувати цей кейс з технічної точки зору та пояснити, що компанія зробила правильно, а де були припущені критичні помилки в архітектурі.

Масштаб катастрофи

"Те, з чим зіткнувся Karabas, – це класична багатовекторна атака на рівні додатків", – пояснює Артем Атаманчук, який протягом своєї кар'єри побудував десятки високонавантажених Kubernetes-кластерів для компаній з мільйонами активних користувачів в понад 70 країнах світу. "Мільйон запитів в секунду – це багато. Для контексту: навіть найсучасніші системи, які я створював для міжнародних платформ, розраховані на обробку близько 100 тисяч одночасних з'єднань. Тут же говоримо про атаку, потужність якої в 10 разів перевищує нормальну роботу великого сервісу".

Особливість цієї атаки полягала в тому, що зловмисники отримали доступ до непублічного API, через яке партнери Karabas формували звіти та робили замовлення. "Це найгірший сценарій, – коментує DevOps-експерт. – Публічні ендпойнти ви можете захистити стандартними засобами: обмеженням швидкості, IP-блокуванням, CDN. Але коли атакують логіку бізнесу через легітимні API з валідними запитами на формування ресурсомісткої звітності – це вже зовсім інший рівень загрози".

Архітектурна вразливість

Аналізуючи технічний стек Karabas того періоду, Атаманчук відразу вказує на системні недоліки: "З опису кейсу видно, що в 2018 році Karabas працював на традиційній серверній інфраструктурі з обмеженою пропускною здатністю. Коли засновник каже про "пропускну здатність в 100 тисяч запитів", він фактично говорить про фізичні обмеження серверів. У сучасній хмарній архітектурі ми оперуємо зовсім іншими масштабами".

За словами експерта, критичною помилкою була відсутність належної сегментації API: "Партнерське API має працювати на окремій інфраструктурі з власними обмеженнями та моніторингом. У моїх проєктах я завжди створюю ізольовані Kubernetes середовища для різних типів навантаження. Тоді, якщо атакують партнерський сервіс, падає тільки він, а клієнтський фронт продовжує працювати".

Що мав би зробити Senior DevOps від початку

"Якби я проектував інфраструктуру для Karabas, я би побудував її на зовсім інших принципах, – ділиться досвідом Атаманчук, який в RubyPlay спроектував гібридну інфраструктуру на GCP та VMware з 99.99% часом роботи для мільйонів активних користувачів щодня.

Перший рівень захисту: edge layer

"Ще до того, як зловмисний трафік досягає ваших серверів, він має пройти через потужний фільтруючий рівень. Я завжди використовую комбінацію Cloudflare та Google Cloud Armor. Cloudflare відсіює до 90% DDoS-трафіку на своєму рівні, застосовуючи глобальні правила та машинне навчання для виявлення аномалій. Cloud Armor додає ще один рівень захисту з можливістю тонкого налаштування правил на рівні Google Cloud Platform".

Другий рівень: захист на рівні додатків

"На рівні застосунків потрібна розумна система обмеження запитів. Я налаштовую NGINX з правилами обмеження: наприклад, не більше 10 запитів на хвилину на один IP для "важких" ендпойнтів звітності. Це зробить атаку економічно невигідною, адже зловмисникам доведеться використовувати в 100 разів більше IP-адрес".

Третій рівень: захист бази данних

"Найкритичніше – захист бази даних. Я впроваджую пул з’єднань, кешування запитів та асинхронну обробку важких запитів через черги повідомлень, такі як RabbitMQ або Kafka. Коли партнер запитує звіт, запит йде в чергу, обробляється в фоні, а результат надсилається через вебхук або стає доступним для завантаження. Таким чином, навіть мільйон запитів на звіти не впливає на базу даних в реальному часі".

Економіка захисту: чому превентивні заходи дешевші

Засновник Karabas оцінює вартість одного дня атаки в 2-3 тис. долл. Атаманчук розгортає більш детальну економічну картину: "Це лише прямі втрати від простою. Додайте сюди вартість екстреної підтримки від CyberLab з погодинною оплатою команди спеціалістів 24/7 впродовж двох тижнів. Потім репутаційні втрати: партнери йдуть до конкурентів, падає SEO, Google припиняє індексацію. Загальні збитки можуть сягати 50 – 100 тисяч долларів".

За розрахунками інженера, превентивна архітектура обійшлася б значно дешевше: "Cloudflare Enterprise з DDoS-захистом – близько 5 тис. долл на рік. Google Cloud Armor – ще 2-3 тис. долл. річних. Належна архітектура Kubernetes з автоскейлінгом та географічним розподілом навантаження – це початкова інвестиція в 20-30 тисяч долларів на налаштування. Сукупно – близько 40 тис. долл. за перший рік. Це вартість витрат двох тижнів під атакою, але з гарантією захисту на роки".

Сучасна альтернатива: як це мало би виглядати сьогодні

Атаманчук описує, як би він створював архітектуру Karabas для 2020 року:

Інфраструктура як код (IaC): "Вся інфраструктура має бути описана в Terraform модулях. Це означає, що якщо хтось знищить ваші сервери, ви за 15 хвилин піднімете ідентичну копію в іншому регіоні. Я використовую Terragrunt для управління середовищами (dev, stage, prod) і Atlantis для GitOps".

Багаторегіональне розгортання: "Сайт має працювати одночасно в трьох географічних регіонах. Якщо атакують європейський дата-центр, трафік автоматично перемикається на США та Азію. Я реалізував таку схему для RubyPlay: незалежні GKE кластери в різних регіонах з Cloud SQL реплікацією. Навіть якщо вийде з ладу цілий регіон Google Cloud, користувачі цього не помітять".

Стек моніторингу: "Критично важливо бачити атаку в реальному часі. Я будую стек на Prometheus + Thanos для метрик, Grafana для візуалізації, New Relic для APM. Це дозволяє за секунди визначити, що трафік аномальний, з яких IP він йде, які ендпойнти атакують. Система автоматично створює алерти, команда отримує сповіщення раніше, ніж користувачі помітять проблему".

Менеджмент чутливих данних: "Той факт, що зловмисники отримали доступ до партнерського API, вказує на можливі проблеми з управлінням чутливими данними. Я впроваджую HashiCorp Vault для централізованого зберігання всіх ключів, токенів та сертифікатів. API ключі ротуються автоматично кожні 90 днів, а для партнерів використовується OAuth 2.0 з короткоживучими токенами".

CI/CD Pipeline для швидкого реагування

"Швидкість реакції залежить від того, наскільки швидко ви можете задеплоїти зміни в продакшн, – пояснює Атаманчук. – Я створив GitLab CI pipeline, який автоматично тестує, сканує на вразливості та деплоїть новий код за 8-12 хвилин від розробки до продакшену. Коли під час атаки ви виявляєте вразливість в коді, можливість виправити її за 10 хвилин замість годин, в цьому критична різниця".

Kubernetes як захисна платформа

"Kubernetes – це фундаментальна зміна підходу до інфраструктури, – наголошує експерт. В Karabas при атаці розробники латали дірки, перезавантажували сервери, вручну переключали трафік. В Kubernetes все це автоматизовано".

Атаманчук описує конкретний сценарій: "Припустимо, один з ваших сервісів споживає надто багато пам'яті через атаку. В традиційній архітектурі це призведе до падіння всього сервера. В моєму K8s setup'і працюють обмеження ресурсів: контейнер фізично не може споживати більше виділеної пам'яті. Якщо він сиплеться, Kubernetes автоматично перезапускає його за секунди. Якщо навантаження зростає, Horizontal Pod Autoscaler створює додаткові копії сервісу".

Помилки, яких можна було уникнути

Аналізуючи рішення Karabas під час атаки, Атаманчук виділяє кілька технічних прорахунків:

1. Реактивний підхід: "Фраза 'коли системні адміністратори помітили атаку' – це вже провал. У 2018, а тим більше в 2020, моніторинг має сповіщати про аномалії автоматично. Я налаштовую SLO-based alerting: якщо затримки зростають на 50% або рівень помилки перевищує 1%, система миттєво алертить. DevOps інженер дізнається про проблему раніше за клієнтів".
2. Ручне блокування IP: "Закривати вручну зарубіжні IP – це кам’яний вік. Сучасні системи використовують геоблокінг на рівні CDN з white-list підходом: дозволяємо тільки трафік з України плюс кілька країн для легітимних користувачів. Це налаштовується за 5 хвилин в Cloudflare".
3. Відсутність обмежень: "Факт того, що один ендпойнт для звітів міг покласти всю систему – це архітектурна катастрофа. Кожен API ендпойнт має мати: ліміт звернень на IP, ключі API, автоматичний блокувальник для захисту сервісів, обмеження часу для запитів".

Чому хмарна міграція – не панацея

Засновник Karabas правильно зауважує, що просте перенесення в хмару не вирішить проблему. Атаманчук уточнює: "Хмарні сервіси дають необмежену масштабованість, але атакуючий трафік теж буде масштабуватися. Секрет в правильній архітектурі. Я використовую багаторівневий захист: 99% DDoS-трафіку відсіюється на CDN (Cloudflare), яка бере фіксовану місячну оплату. До хмарної інфраструктури доходить тільки легітимний або дуже складний злочинний трафік, який уже фільтрується Cloud Armor. На рівні додатків працює NGINX обмеження, і тільки валідні запити доходять до Kubernetes та баз даних. За такої схеми навіть під атакою хмарні витрати зростають максимум на 20-30%".

Висновки: що мав би зробити Karabas інакше

"Karabas вижив завдяки швидкій реакції та готовності інвестувати в зовнішніх експертів. Але більшості проблем можна було уникнути при правильній початковій архітектурі", – каже інженер.

"Три критичні помилки: відсутність належного захисту на рівні CDN, не сегментована API інфраструктура, відсутність автоматизованого моніторингу та алертів. Виправлення кожної з цих проблем займає 1-2 тижні роботи досвідченого DevOps інженера".

"Але найважливіший урок, – це те, що безпека та надійність мають бути частиною архітектури з першого дня. Коли ви проектуєте систему, яка обробляє мільйони транзакцій, ви маєте закладати надійність як основну вимогу поряд з функціональністю", – підсумовує Артем Атаманчук

Про експерта: Артем Атаманчук – Senior DevOps Engineer з 7-річним досвідом проектування та підтримки високонавантажених систем. Спеціалізується на Kubernetes архітектурі, хмарній інфраструктурі (GCP, VMware), автоматизації та безпеці. В RubyPlay спроектував гібридну інфраструктуру, яка обслуговує мільйони користувачів щодня з 99.99% часом роботи. Експерт в галузі IaC, CI/CD автоматизації, моніторингу та оптимізації витрат. Регулярно проводить аудити кібербезпеки для технологічних компаній та консультує стартапи з питань DevOps трансформації.