Що таке DoS
DoS — це відмова в обслуговуванні. Сервіс ще живий, але він витрачає сили на те, щоб обробити зайве навантаження, і через це перестає нормально відповідати людям.
У простому житті це виглядає так: сайт відкривається повільно, форма не відправляється, API повертає помилки, а підтримка отримує повідомлення в стилі «у вас все лежить». Не завжди це атака. Але якщо схожий стан з’являється раптово і без видимої причини, DoS — один із перших підозрюваних.
Чим DoS відрізняється від DDoS
DoS зазвичай означає одну точку тиску або дуже вузьке джерело навантаження. Це може бути один вузол, один скрипт або одна надто дорога дія, яка змушує систему задихатися.
DDoS — це розподілена відмова в обслуговуванні. Тут тиск іде з багатьох пристроїв одночасно, часто через botnet. Через це блокувати джерело важче: у вас не одна адреса, а багато, і вони можуть змінюватися дуже швидко.
Коротко: DoS — це «завалили вхід». DDoS — це «завалили вхід із багатьох боків одразу».
Чому це важливо
Проблема не лише в технічній красі графіків. Коли сервіс втрачає доступність, він починає бити по бізнесу:
- не проходять замовлення або оплати;
- ламаються особисті кабінети й форми;
- росте черга звернень у підтримку;
- падає довіра до сервісу;
- команда витрачає години на ручне гасіння замість нормальної роботи.
Найнеприємніше те, що DoS часто схожий на звичайний сплеск трафіку. Зовні це може виглядати як «нам просто пощастило з рекламою» або «щось зламалося після релізу». Тому потрібні не здогадки, а базові сигнали.
Ілюстрація
На схемі видно просту річ: звичайний трафік приходить рівно, а під час атаки хвиля запитів забиває сервіс і штовхає його в помилки та затримки.
Як розпізнати проблему
Починай із фактів, а не з паніки.
1. Подивись на симптоми
Типові ознаки:
- різкий ріст 5xx;
- повільні відповіді навіть на прості запити;
- стрибок CPU або RAM;
- збільшення кількості з’єднань;
- однакові маршрути повторюються знову і знову.
Якщо у вас росте лише один екран або один endpoint, це може бути просто важкий код. Якщо ж починає задихатися все одразу, підозра на DoS стає сильнішою.
2. Порівняй із нормальною базою
Будь-який сервіс має свій звичний ритм. Корисно знати:
- скільки запитів приходить у спокійний день;
- які маршрути найважчі;
- де є публічний доступ без логіну;
- що має бути доступним завжди, навіть під навантаженням.
Без цієї бази будь-який сплеск здається катастрофою або, навпаки, «просто піком трафіку». І те, і інше погано.
3. Відрізни атаку від звичайного піку
Не кожен сплеск — це DDoS. Іноді це:
- розсилка на пошту або в соцмережах;
- реліз, який різко підняв інтерес;
- кеш, що перестав працювати;
- важкий запит, який почали повторювати сотні клієнтів.
Але якщо навантаження приходить із багатьох адрес, пов’язане з однаковими маршрутами й швидко змінюється, це вже схоже на DDoS, а не на успіх маркетингу.
Як захищати сервіс
Найкращий захист — не один чарівний перемикач, а кілька шарів.
1. Поставити простий бар’єр на вході
Для публічних маршрутів корисні WAF і rate limiting. Вони не роблять сервіс невразливим, але допомагають відрізати частину шуму ще до того, як він з’їсть усі ресурси.
2. Зробити дорогі речі дорожчими для атакувальника
Не дозволяй важким операціям запускатися без потреби. Якщо запит потребує багато роботи, постав додаткову перевірку або окремий маршрут. Добре працює й кешування там, де зміни не щосекундні.
Якщо у тебе вже є CDN, він може забрати частину шуму ще до застосунку. Кеш працює в тому ж дусі: менше повних перерахунків, менше шансів задихнутися.
3. Залишити простий шлях для найважливішого
Домашня сторінка, health checks і критичні екрани мають виживати довше за все інше. Якщо все одно доводиться економити ресурси, нехай сервіс хоча б залишається зрозумілим і керованим.
4. Обмежити те, що легко з’їдає ресурс
Стеж за великими файлами, довгими запитами, повторними спробами й дуже дорогими маршрутами. Часто саме вони перетворюють легкий сплеск у реальну проблему.
5. Мати план для інциденту
Потрібно заздалегідь знати:
- хто дивиться метрики;
- хто приймає рішення;
- де вмикаються захисні обмеження;
- кого дзвонити провайдеру або хостеру;
- як повернути зміни назад, якщо стало гірше.
Перші 15 хвилин підозри
Якщо сервіс почав задихатися, не роби десять змін одразу.
- Перевір, чи проблема на всьому сервісі, чи лише на одному маршруті.
- Подивись на 5xx, CPU, RAM і кількість з’єднань.
- Зістав це з останнім релізом або змінами конфігурації.
- Увімкни або посиль WAF і rate limiting там, де це безпечно.
- Зберіть логи й коротко зафіксуйте, що саме сталося.
Тут важлива дисципліна: спочатку стабілізація, потім аналіз, потім точкове покращення.
Типові помилки
- думати, що DoS буває лише «великим і страшним»;
- плутати атаку зі звичайним піком трафіку;
- масштаувати все навмання без базового захисту;
- вимикати захист після першого покращення;
- не мати графіків і логів, коли вони вже дуже потрібні.
Висновок / план дій
DoS б’є по доступності. DDoS — це та сама проблема, але з багатьох джерел і в помітно складнішому масштабі.
Нормальний порядок дій такий:
- зрозуміти, що саме зламалось;
- відрізнити атаку від звичайного піку;
- увімкнути WAF, rate limiting і інші прості бар’єри;
- захистити найважливіші маршрути;
- зафіксувати план на наступний раз.
DoS — це не причина панікувати. Це причина мати шарову оборону й спокійний план реагування.
Офіційні джерела: