DDoS-захист на ZevsHost
Усі сервери ZevsHost захищені від DDoS-атак на рівнях L3, L4 і (у дата-центрах USA та OVH) L7. Мета атаки — не вкрасти дані, а зробити сервіс недоступним для звичайних відвідувачів за рахунок вичерпання якогось ресурсу: смуги каналу, обчислювальних потужностей сервера або ліміту одночасних з'єднань.
DDoS розшифровується як Distributed Denial of Service — розподілена відмова в обслуговуванні. Ключове слово «розподілена»: атака йде не з однієї адреси, яку можна просто заблокувати, а з тисяч або мільйонів заражених пристроїв одночасно (ботнета). Саме тому захист будується на аналізі патернів трафіку, а не на списку конкретних шкідливих IP.
Рівні захисту
- L3 — фільтрація шкідливого трафіку на рівні мережі (IP-адреси, протоколи)
- L4 — захист на рівні транспортного протоколу (TCP/UDP flood)
- L7 — захист на рівні застосунків (HTTP-флуд, slowloris)
Як виглядають типові атаки
| Тип атаки | Рівень | Ознака в логах чи моніторингу |
|---|---|---|
| SYN flood | L4 | Багато напіввідкритих TCP-з'єднань у стані SYN_RECV |
| UDP amplification (DNS, NTP) | L3/L4 | Різке зростання вхідного трафіку з чужих відкритих DNS/NTP-серверів |
| HTTP flood | L7 | Тисячі однотипних GET-запитів із різних IP на одну й ту саму URL |
| Slowloris | L7 | Багато відкритих з'єднань, які тримаються, але майже не передають дані |
Рівні L3 і L4 фільтруються на межі мережі провайдера до того, як трафік доходить до вашого сервера. Рівень L7 вимагає розуміння логіки протоколу HTTP, тому доступний лише на майданчиках із відповідним обладнанням — див. таблицю вище.
Як відрізнити атаку від органічного сплеску
Не будь-яке різке зростання трафіку — це атака. Різниця видна за патерном запитів:
- Органічний сплеск (наприклад, після публікації в ЗМІ) — різні URL, різні User-Agent, поведінка схожа на звичайних відвідувачів.
- Атака — однотипні запити на одну URL чи endpoint, аномально малий розкид у часі між запитами, багато запитів із підмереж, не характерних для вашої аудиторії.
Автоматична фільтрація іноді помиляється в обидва боки: пропускає повільну, розтягнуту в часі атаку під виглядом звичайного навантаження або тимчасово сповільнює відповідь легітимним користувачам під час різкого сплеску інтересу до сайту. Повністю виключити хибні спрацювання неможливо — завдання системи захисту в тому, щоб їх було помітно менше, ніж реальної шкоди від пропущеної атаки.
Що відбувається під час атаки
- Система автоматично виявляє аномальний трафік
- Шкідливі пакети фільтруються до досягнення сервера
- Легітимний трафік проходить без затримок
- Служба моніторингу сповіщає команду про великі атаки
Чого DDoS-захист не покриває
- Брутфорс пароля з однієї або кількох IP невеликою кількістю запитів — це не DDoS за обсягом, від нього захищає fail2ban і ліміт спроб входу, а не мережевий фільтр.
- Вразливість у коді застосунку, яку експлуатують поодинокими запитами — фільтрація трафіку не перевіряє логіку вашого коду.
- Перевантаження від власного легітимного зростання аудиторії — тут потрібен масштабований сервер і кешування, а не захист від атак.
При атаці
Створіть тікет у підтримку — ми можемо застосувати додаткові правила фільтрації.
Поки тікет обробляється, частину заходів можна застосувати самостійно, якщо у вас є доступ до сервера і, якщо він використовується, до панелі Cloudflare:
- Увімкніть режим Under Attack Mode в Cloudflare, якщо домен вже підключений — він додає проміжну перевірку браузера перед кожним запитом.
- Тимчасово обмежте кількість одночасних з'єднань з однієї IP на Nginx через
limit_conn, щоб знизити навантаження від окремих агресивних клієнтів, поки фільтрація не запрацює в повну силу. - Зафіксуйте точний час початку атаки і збережіть зразок логів — це пришвидшить розбір на боці підтримки і підбір точних правил фільтрації.
Як перевірити, що фільтрація дійсно працює
- Подивіться заголовки відповіді сервера при звичайному запиті — на майданчиках із L7 через Cloudflare у них присутній
cf-ray, що підтверджує проходження трафіку через фільтруючий вузол. - Під час реальної атаки звірте обсяг вхідного трафіку на мережевому інтерфейсі (
vnstatабо панель моніторингу) з навантаженням на сам сервіс — при працюючій фільтрації сервіс залишається чутливим навіть за великого вхідного обсягу. - Після інциденту запросіть у підтримки звіт про фільтрацію — легітимні звернення не мають потрапляти в число відкинутих пакетів.
Як налаштувати додатковий рівень захисту через проксі перед сервером — у статті DDoS-захист Nginx і Cloudflare, а базові правила файрвола — у розборі UFW на VPS.
Часті питання
Чи потрібно окремо підключати або оплачувати DDoS-захист на серверах ZevsHost?
Окремо підключати захист не потрібно: рівні L3 і L4 працюють автоматично на кожному сервері ZevsHost без додаткового налаштування. Рівень L7 доступний не всюди — він залежить від дата-центру і потребує відповідного обладнання для аналізу HTTP-трафіку. Тому його наявність визначається обраним майданчиком розміщення сервера, а не окремою купівлею чи налаштуванням клієнта.
Що робити, якщо фільтрація випадково сповільнює доступ звичайним відвідувачам?
Повністю уникнути хибних спрацювань неможливо: під час різкого сплеску інтересу до сайту фільтрація іноді ненадовго сповільнює відповідь навіть звичайним відвідувачам. Якщо затримки помітні і тримаються довго, варто надіслати тікет у підтримку — фахівці скоригують правила фільтрації вручну і скоротять кількість подібних випадків, не чекаючи, поки навантаження спаде саме.
Чи захищає DDoS-захист від злому через вразливість у коді сайту?
Ні. Мережева фільтрація трафіку аналізує лише патерни запитів і їхній обсяг, а не логіку вашого застосунку, тому вразливість, яку експлуатують одиничними звертаннями, вона не виявляє і не закриває. Від таких атак захищають оновлення коду, аудит безпеки і моніторинг логів самого застосунку — це окреме завдання, не пов'язане з мережевим захистом.
Що можна зробити самостійно, доки тікет у підтримку ще не опрацьований?
Доки тікет опрацьовують, можна увімкнути режим Under Attack Mode в Cloudflare, якщо домен вже підключений до цієї панелі, — він додає додаткову перевірку браузера перед кожним запитом. На Nginx варто тимчасово обмежити кількість з'єднань з однієї адреси, а також зафіксувати точний час початку атаки і зберегти зразок логів для підтримки.