DDoS‑атаки давно не є проблемою лише «великих». Сьогодні навіть невеликий сайт із промокампанією чи локальним трафіком може отримати хвилю сміттєвих запитів і «впасти». Гарна новина – 80% ризиків закриваються простими, дешевими і швидкими діями: правильний DNS, базова фільтрація на периметрі, кешування, rate‑limit і дисципліна конфігурацій. Цей матеріал – практичний гайд без магії та маркетингу: які атаки бувають, що реально працює, що можна зробити за один вечір і як не переплатити складністю.
Як це працює (види атак і точки захисту)
Рівні моделі та поверхні ураження
- L3/L4 (мережа/транспорт): SYN‑flood, UDP‑flood, ICMP‑flood, фрагментація, відбиті ампліфікації (NTP, DNS, CLDAP тощо). Мета – забити канал/стек.
- L7 (рівень застосунків): HTTP‑flood, Slowloris/slow‑read, хвилі на «важкі» ендпоїнти (пошук, кошик), «Rapid Reset»/пило‑атаки в HTTP/2 або шторм у HTTP/3/QUIC. Мета – виснажити CPU/БД/черги.
Де фільтрувати
- Перед вашим сервером – глобальна мережа фільтрації (Anycast) + CDN/WAF. Це найефективніший і найдешевший рівень для малого сайту: удар приймає чужий периметр.
- На вході до майданчика – фільтрація в провайдера/дата‑центрі, «чистий канал», ACL на бордері.
- На вашому сервері – системні ліміти, файрвол, веб‑сервер/проксі, кеш, обмеження на рівні застосунку.
Стійкість дає багатошарова оборона: частина сміття не дійде до вашого ДЦ, частину відріже файрвол, залишки «переварять» кеш і ліміти в застосунку.
Чому це важливо (і чому «потужніший сервер» не рятує)
- Ширина каналу ≠ броня. Атаки часто вузькі: б’ють по таблицях станів, воркерах TLS, чергах, «важких» SQL. Подвоєння CPU не допоможе проти шторму повільних конектів.
- Надійність = репутація. Навіть година офлайну в день релізу спалює бюджет і довіру користувачів.
- Ціна помилки. Неправильний редірект‑луп або вимкнений кеш під навантаженням = DoS «своїми руками». Правильні дефолти дешевші за будь‑яку підписку анти‑DDoS.
Як обирати захист (пріоритети для малого сайту)
Нижче – покроковий план із 12 кроків, розбитих на три рівні. Рухайтеся по порядку й зупиняйтесь, коли ризики та бюджет зійшлися.
Рівень 1 – «Зробити за вечір» (мінімум витрат)
- Тямущий DNS
- Два й більше NS різних провайдерів/зон відмови.
- Розумні TTL: короткі (5–15 хв) для A/AAAA сайту, довгі – для статичних записів.
- Ховайте «прямий» origin‑IP (не світіть його в A‑записах підпроєктів, пошти, панелі).
- CDN/Reverse‑Proxy перед сайтом
- Увімкніть повний кеш статичних ресурсів (Cache-Control із довгим TTL, ETag, gzip/brotli).
- Для популярних HTML увімкніть «edge‑кеш» із коротким TTL і інвалідацією під реліз.
- Мінімізуйте проходи до origin – що менше запитів доходить до сервера, то важче вас «задавити».
- Базовий WAF/захист від ботів
- Дозвольте лише потрібні методи (GET/HEAD/POST), решту блокуйте.
- Сховайте адмінку: доступ за IP/ASN/країною та/або обов’язковий challenge (JS/капча).
- Увімкніть готові правила проти SQLi/XSS/сканерів і ліміти частоти на «дорогих» ендпоїнтах.
- Rate‑limit на периметрі та в себе
- Ліміт по IP/префіксу/токену, окремі квоти для важких операцій (пошук, логін, відправка форм).
- Грейс‑період і «відро токенів» (burst), аби не чіпати чесних користувачів.
- Кеш на рівні застосунку
- Кешуйте HTML‑фрагменти, меню, прелюди, повільні віджети.
- Винесіть сесії/кеш у Redis/Memcached, тримайте «гарячі» ключі в пам’яті.
- HTTP/2 та HTTP/3 – але з обмеженнями
- Обмежте паралельність потоків/кадрів, забороніть «висячі» повільні потоки, увімкніть захист від «rapid reset».
- Вимкніть непотрібні екзотичні функції, що збільшують площу атаки.
Рівень 2 – «Тиждень на впорядкування»
- Файрвол і мережеві ліміти
- nf_conntrack/таблиці станів – із запасом і алертами, але з антискан‑лімітами.
- SYN‑cookies, обмеження напівз’єднань, drop усього зайвого (старі протоколи/порти).
- Простий ACL: ріжемо «злі» ASN/гео, де немає ваших користувачів.
- Закрийте «чорні ходи» до origin
- Забороніть прямий доступ до origin по IP: лише через проксі/CDN (списки довірених IP, mTLS, правила firewall).
- Для адмінки/API – окремий піддомен зі своїм режимом доступу.
- Здоровий TLS
- Профілі шифрів без «зоопарку», HSTS, автопродовження сертифікатів.
- Пріоритезуйте сучасні шифри, обмежте renegotiation/компресію.
- Зразковий веб‑сервер/проксі
- Обмеження на розмір заголовків/тіла, таймаути очікування, max з’єднань, ліміти воркерів/пам’яті.
- Адекватний keepalive і буфери, щоб «slow‑read» не душив воркери.
- Сигнали й алерти
- Моніторте RPS, p95, 5xx, частку кеш‑HIT, кількість відкритих з’єднань, conntrack, SYN backlog.
- Алерти з консолідацією за кореневою причиною: один інцидент – одне сповіщення.
- Резервний сценарій (дефенсивна деградація)
- Підготуйте «легку» версію головної сторінки (без важких віджетів), яку можна швидко ввімкнути.
- Фолбек для критичних API: черги/кеш відповіді/заглушки.
Рівень 3 – «Надмірність і готовність»
- Два незалежні origin’и (active‑passive або active‑active) із синхронізацією.
- Geo‑балансування й Anycast‑периметр.
- Розділення публічної та адміністративної площини (різні домени/канали/ключі).
- Учбові тривоги: раз на квартал симулюйте атаку (м’яко) і вимірюйте MTTA/MTTR.
Конкретика: рецепти проти типових атак
- SYN‑flood (L4): увімкнути SYN‑cookies; збільшити backlog і таймаути напівз’єднань; на бордері/у провайдера – фільтрація spoofed‑джерел; ліміт нових конектів/сек.
- UDP‑flood/ампліфікація: відрізати зайві UDP‑сервіси; обмежити швидкість/сек на порт; фільтри за відомими рефлекторами; на периметрі – «поглинач» UDP.
- Slowloris/slow‑read (L7): ліміти заголовків/тіла, таймаут на перший байт, мінімальна швидкість клієнта, обмеження паралельних запитів на IP, обрив «висячих» з’єднань.
- HTTP‑flood по важких сторінках: агресивний кеш (edge+app), JS‑challenge/капча для підозрілих user‑agent/ASN, індивідуальний rate‑limit на ендпоїнт, пререндер і зменшення ваги відповіді.
- Брутфорс/скрейпінг: поведінкові правила, блок по IP/ASN/гео, обов’язковий JS/капча при аномаліях, «медові» ендпоїнти для пастки сканерів, захист контенту (robots/headers/сповільнення видачі).
Помилки, що ламають стійкість частіше, ніж атаки
- Немає кешу HTML (CMS рендерить кожну головну сторінку наново).
- Origin доступний напряму по IP і оминає WAF/CDN.
- Немає лімітів/таймаутів у веб‑сервері та застосунку.
- Відкриті адмінки в інтернеті без IP‑фільтра чи 2FA.
- Змішана статика і БД на одному диску/томі: сплеск логів/статик «глушить» БД.
- Секрети/ключі у публічних репо → їх використовують для обходу перевірок.
- Одна точка відмови: один NS‑провайдер, одна зона, один балансувальник.
Чек‑лист «налаштувати за один вечір» (реалістично)
- Два NS, TTL 5–15 хв для A/AAAA сайту.
- Підключений периметр (CDN/WAF), origin прихований і приймає трафік лише від довірених IP.
- Edge‑кеш статик + короткий кеш HTML, автоінвалідація під реліз.
- Дозволені методи GET/HEAD/POST, адмінка – за IP + challenge.
- Rate‑limit на важких ендпоїнтах, «відро токенів» із burst.
- Обмежені заголовки/тіло, виставлені таймаути (connect/read/send).
- SYN‑cookies увімкнено, conntrack під алертами, drop «сміттєвих» портів.
- Моніторинг p95/5xx/кеш‑HIT/відкритих з’єднань + алерти.
- Тест‑план: короткий стрес (ab/k6/locust) або м’який challenge через периметр.
- Легка сторінка/режим деградації – готові й задокументовані.
Плейбук інциденту: дії, коли «горить»
- Підтвердити: кілька незалежних перевірок (із 2–3 регіонів).
- Увімкнути посилені правила на периметрі: «підозрілі» AS/гео → challenge, агресивний rate‑limit на гарячих ендпоїнтах.
- Знизити навантаження: підвищити TTL кешу HTML/JSON, відкласти фонові вагомі задачі, увімкнути легку сторінку.
- Захистити origin: тимчасово закрити прямий IP, розширити список довірених мереж проксі, підняти ліміти conntrack/воркерів.
- Комунікація: статус‑сторінка, короткі оновлення користувачам («підвищене навантаження, доступ відновлюється»).
- Постмортем: що пропустили алерти, де був «тонкий» вузол, які дефолти змінити.
Скільки це коштує (прагматично)
- $0–$20/міс: базовий CDN/WAF‑периметр; правил достатньо для малих сайтів; edge‑кеш, прості rate‑ліміти, обмеження методів, IP‑фільтри.
- $20–$100/міс: + антибот/челенджі, налаштовні правила L7, звіти та алерти, розширені ліміти.
- $100+: преміальні функції, пріоритетна фільтрація L3/L4, окремі політики, geo‑балансування, SLA.
На своїй стороні – кілька годин інженера на старт і зрідка коригування з урахуванням трафіку.
Як міряти успіх захисту
- Доступність (%) і помилки (5xx/4xx) – по ключових ендпоїнтах.
- Латентність p95/p99 – чи не погіршилась через фільтрацію.
- Коефіцієнт кеш‑HIT – ціль > 80% по статиці, > 50% по HTML у піки.
- Частка запитів, що пішли в challenge/блок – показник «шуму» і ефективності правил.
- Навантаження origin (CPU/пам’ять/з’єднання) за зіставного RPS до/після.
Чому Unihost
Мережа і периметр. Маршрутизація та піринг налаштовані на низьку p95‑латентність; на периметрі – фільтрація сміттєвого трафіку. Приватні VLAN спрощують сегментацію публічної й адміністративної площин.
Сервери під навантаження. NVMe Gen4/Gen5, швидкі CPU, передбачуваний uplink; синергія кешу (edge+app) і виділені ресурси під БД/черги.
Безпека за замовчуванням. Шаблони firewall/ACL, закриття origin від прямого доступу, автоматичне оновлення TLS‑сертифікатів, готові правила для обмеження методів/заголовків/розмірів.
Спостережність. Інтеграції з Prometheus/Grafana/ELK/OTel, алерти на conntrack/SYN backlog, статус‑сторінка і пост‑інцидентні звіти.
Масштабованість. Почніть на VPS, переходьте на виділені сервери без зміни провайдера і зламу схеми – конфігурації переїдуть разом з інфраструктурою через IaC.
TL;DR
Для малого сайту захист від DDoS – це дисципліна й десяток правильних налаштувань, а не «чарівна коробка». Сховайте origin за периметром, дозвольте кешу робити свою роботу, поставте розумні ліміти, закрийте адмінку, увімкніть алерти і тримайте план деградації. У 8 з 10 випадків цього досить, щоб пережити сплески й «копійчані» атаки.
Спробуйте сервери Unihost – стабільна інфраструктура для ваших проєктів.
Замовляйте VPS або виділений сервер на Unihost, увімкніть периметр‑захист і кеш – і пройдіть наступну атаку без даунтайму.