Налаштування DDoS protection: що ламається без захисту периметра
Піковий сплеск запитів рідко виглядає як атака в логах: канал забивається підпискою, черга з'єднань на балансувальнику зростає, і застосунок починає відповідати за залишковим принципом.
Перевантаження каналу запитами з'їдає той запас, який закладали під розпродаж або ранковий пік, — відмова приходить раніше, ніж моніторинг встигає подати виразний сигнал.
Далі спрацьовує ефект доміно: недоступність сервісу під навантаженням б'є саме по тих клієнтах, які приносять виручку, — по оплаті, оформленню замовлення, особистому кабінету. Чергова зміна в цей момент гасить наслідок: перезапускає вузли, розширює пул, підкручує ліміти.
Причина — шкідливий трафік, що дійшов до застосунку, — залишається на місці й повертається на наступному піку.
Саморобні фільтри на цьому тлі бувають небезпечнішими за саму атаку: хибні спрацювання фільтра відсікають живих користувачів за геолокацією або за поведінкою, і разом зі сміттям ідуть реальні замовлення.
Захист периметра — наприклад, на Cloudflare — влаштований інакше: шкідливий трафік гаситься на межі, до того як займе канал і чергу застосунку.
Налаштування ddos protection — це не увімкнена галочка, а набір порогів, режимів і правил під профіль вашого трафіку: де вмикати перевірку, які джерела вважати довіреними, за яких рівнів піднімати чутливість, щоб не зачепити своїх. Нижче розбираємо, як це закривається — від схеми фільтрації до порядку дій у момент атаки.
Що змінюється після вмикання фільтрації: п'ять вимірюваних ефектів
Фільтрація трафіку — не тумблер «увімкнути й забути»: ефект проявляється в метриках, які чергова зміна дивиться щоранку. Нижче п'ять показників, які зсуваються передбачувано, якщо правила фільтрації та пороги виставлені під профіль вашого трафіку, а не залишені за замовчуванням.
Доступність під піковим навантаженням
Сміттєві запити відсікаються на периферії й до застосунків не доходять — сервіс перестає провалюватися в години пік. Замість хвилин недоступності на графіку залишається рівна полиця, а розширювати пул під кожен сплеск більше не потрібно. Перевіряємо це синтетичним залпом із зовнішніх точок, а не за звітами самого фільтра.
Час відновлення після сплеску
Атака обривається на вході, внутрішні сервіси не накопичують чергу й не втрачають з'єднання. Час відновлення вимірюється десятками секунд замість хвилин ручних перемикань, і в більшості випадків черговий дізнається про спробу вже після її відбиття — з журналу.
Частка відбитого сміттєвого трафіку
Налаштовані сигнатури та поведінкові правила знімають основну частину паразитного навантаження — на бекенд доходить лише трафік з осмисленими запитами.
Різниця видна за кількістю звернень до застосунку при незмінному обсязі вхідного потоку: внутрішня інфраструктура перестає бути вузьким місцем.
Усунений клас відмов
Зникає цілий клас аварій, де причина — вичерпання з'єднань або переповнення черги під навалою ботів. Інциденти такого типу просто перестають відкриватися, і розбір іде не за «чому впало», а за «скільки відбили». Це змінює й характер чергування: нічні підйоми з однотипної причини зникають.
Навантаження на чергову зміну
Обсяг ручних розборів перестає зростати разом із кількістю спроб: типові сценарії закриті правилами, а не реакцією інженера. Зміна витрачає час на тюнінг порогів і розбір аномалій, а не на гасіння тієї самої відмови.
Окремо перевіряємо, що легітимні піки — розпродажі, кампанії, партнерські інтеграції — проходять без хибних блокувань. Схему захисту будуємо на Cloudflare або вбудованих засобах хмари — вибір залежить від того, де живе трафік і хто відповідає за правила.
Порівняння режимів захисту периметра: коли який підходить
Режим захисту обирають не за потужністю сервісу, а за класом атак і за тим, що відбувається з трафіком у спокійний час. Звідси три розвилки: на якому рівні ухвалюється рішення про відкидання пакетів, де фізично стоїть фільтр і як швидко перемикається маршрут під час атаки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудований захист хмарного провайдера | Сервіс живе у хмарі, атаки мережеві та об'ємні | Фільтрація прикладного рівня обмежена шаблонами, тонка логіка під власний протокол недоступна |
| Зовнішній фільтр на периметрі | Потрібні правила під власний застосунок і єдина точка для кількох майданчиків | Трафік іде через третю сторону: затримка, шифрування, юридичний бік |
| Локальний фільтр на власному майданчику | Є власна мережа й канал, важлива суверенність даних | Пропускна здатність каналу — стеля: при переповненні атака лягає на аплінк |
| Гібрид з аварійним перемиканням | Потрібен постійний фільтр плюс черговий контур на пікові атаки | Два набори правил, узгоджені пороги, регулярні навчання на перемикання |
Постійний фільтр проти чергового режиму
Постійний фільтр тримає трафік через захисний контур завжди: правила обкатані, поведінка передбачувана, але затримка додається до кожного запиту. Черговий режим вмикають тільки під час атаки — перемиканням DNS з малим TTL або анонсом адрес, — решту часу трафік іде напряму.
Пороги чергового режиму налаштовують за звичайним профілем трафіку й проганяють на навчаннях: інакше в момент атаки з'ясовується, що частина правил блокує легітимних клієнтів.
Обмеження будь-якого режиму — не потужність фільтра, а точність правил: занадто широка заборона б'є по доступності сильніше за саму атаку.
Порядок впровадження: від аудиту трафіку до передачі в експлуатацію
Роботи йдуть так, щоб захист увімкнувся без зупинки сервісу й без блокування живого трафіку: спочатку фіксуємо, як запити доходять до застосунку, потім обираємо точку вмикання фільтра, і лише потім налаштовуємо пороги.
Аудит і схема трафіку
Збираємо карту: домени, реальні джерела запитів, балансувальники, проксі, зовнішні сервіси за зворотними викликами.
Окремо перевіряємо, чи зберігається адреса клієнта на всьому шляху — від цього залежить, чи відрізнить фільтр бота від людини і чи не заблокує добросовісних відвідувачів.
- Знімаємо схему проходження трафіку — від точки входу до застосунку, із зазначенням, який вузол що приймає і де видно справжні адреси клієнтів.
- Обираємо точку вмикання фільтра: зовнішній периметр очищення (Cloudflare, AWS Shield, Cloud Armor), балансувальник або ділянку перед конкретним сервісом. Фіксуємо, що фільтрується завжди, а що — за розкладом.
- Налаштовуємо пороги спрацювання та правила: базову лінію запитів на користувача, ліміти за частотою, ознаки аномалій, винятки для моніторингу та партнерських інтеграцій.
- Перевіряємо захист на навчальній атаці — керованому сплеску з тестового контуру: які правила спрацювали і чи не пішов у блокування звичайний трафік.
- Навчаємо зміну: як читати панель, що робити при спрацюванні, як тимчасово послабити фільтр, не відкриваючи периметр повністю.
- Вводимо захист в експлуатацію: вмикаємо режим блокування, закріплюємо регламент чергування й точку швидкого відкату.
Перевірка на навчальному сплеску
Сплеск показує, за якого профілю навантаження спрацьовує правило і за який час відновлюється звичайна робота сервісу. За підсумками коригуємо пороги: знімаємо зайві блокування й посилюємо те, що пропустило навантаження. На виході захист увімкнено, перевірено й передано зміні — з регламентом і точкою відкату.
Документи й артефакти, які передаємо після впровадження
Впровадження захисту закінчується не вмиканням фільтрації, а передачею комплекту, за яким ваша команда працює далі без нас: розбирається в схемі, змінює пороги, вводить у курс чергового. Нижче — що залишається у вас на руках.
- Схема проходження трафіку — шлях запиту від зовнішнього контуру до балансувальника й застосунків, точки фільтрації, ділянки, які захист не покриває.
- Конфігурація правил фільтрації та порогів: сигнатури, обмеження за частотою запитів, списки винятків, режим спостереження для нових правил.
- Політики доступу до панелі керування — окремі облікові записи замість спільного, обов'язкова двофакторна автентифікація, межі прав за ролями.
- Журнал змін налаштувань — що, коли і навіщо правили, хто погодив, як відкотити: без нього розбір інциденту перетворюється на здогади.
- Інструкція із самостійного правлення порогів — де безпечна межа, а де починаються блокування живих клієнтів.
- Чек-лист перевірки після змін — набір запитів і сценаріїв, якими черговий переконується, що легітимний трафік проходить.
Регламент дій під час атаки
Це документ на одну-дві сторінки, який читають у момент інциденту, а не в спокійний день.
У ньому — ознаки атаки й пороги спрацювання, порядок ескалації з іменами та каналами зв'язку, перші дії чергової зміни, критерії переходу на посилений профіль захисту й повернення до звичайного. Окремо — що фіксувати в журналі за підсумками.
Кейс: як прибрали сплески відмов на піку навантаження
Клієнт — сервіс з вираженим добовим піком: вечірні години й старт розпродажів давали кратне зростання звернень, а разом із ним приходив сміттєвий трафік — сканери, боти, повтори запитів до динамічних сторінок.
Периметр пропускав усе підряд, і застосунок упирався в межу раніше, ніж приходило справжнє навантаження.
Що було до
Пік тривав 40–60 хвилин. Частка запитів, що дійшли до застосунку, просідала до 55% — решта втрачалася на очікуванні відповіді. Час недоступності в пік сягав до 12 хвилин за вечір: частина користувачів бачила помилки й ішла.
Інженери розбирали 5–7 нічних інцидентів на місяць, кожен — із ручним розширенням потужностей і розбором журналів.
Що стало після
Захист периметра зібрали на Cloudflare і розвели правила за шарами: спочатку відсів за поведінкою та репутацією адрес, потім обмеження частоти для чутливих маршрутів, і лише після цього — черга до застосунку.
Частка відбитого сміття — близько 30% вхідного потоку, а частка корисних запитів, що дійшли до застосунку, зросла до 97%.
За місяць спостережень недоступності в пік не зафіксовано, помилки на вході зникли зі звітів. Нічні розбори змінилися плановим розбором аномалій раз на тиждень. Статика й кеш віддаються з периметра, тому зростання піку перестало перекладатися на застосунок.
Чим відрізняється фільтрація DDoS на мережі від захисту застосунку
Мережевий фільтр працює з потоком, а не з вмістом запиту: він оцінює обсяг, адресу джерела, частоту нових з'єднань і розподіл за портами. Такий фільтр гасить об'ємні сплески — ампліфікації, SYN-флуд, ботові мережі — до того, як трафік займе канал до серверів. Але шкідливий запит від корисного він не відрізняє, якщо той виглядає як звичайний.
Захист застосунку дивиться всередину запиту: маршрут, заголовки, тіло, частоту звернень до конкретної форми, поведінку сесії.
Тут відбиваються цільові атаки — сплеск на сторінку авторизації, перебір облікових даних, повільні запити, які тримають з'єднання відкритим і майже непомітні за обсягом.
| Рівень захисту | Що відбиває | Що залишається незакритим |
|---|---|---|
| Мережа й транспорт | Об'ємні потоки, ампліфікації, SYN-флуд | Повільні атаки та «легітимний» трафік з корисною формою запиту |
| Застосунок | Сплески на конкретний маршрут, перебір, аномалії сесій | Обсяг, який забиває канал ще до розбору запиту |
| Суміщена схема | Обсяг на вході плюс аномалії за змістом на виході | Потребує узгоджених порогів, інакше ріжеться корисний трафік |
Жоден рівень не є самодостатнім. Без мережі канал і балансувальник упираються в стелю раніше, ніж спрацюють правила застосунку, і до них просто не доходить запит. Без застосунку все, що схоже на нормальне звернення, проходить наскрізь — фільтр бачить рівний потік і не реагує.
Інструменти на кшталт Cloudflare дають обидві площини в одному контурі: спочатку вмикаються мережеві правила, потім правила застосунку з порогами під реальний профіль трафіку.
Суміщення рівнів і є робочою схемою — фільтр тримає обсяг, застосунок ріже аномалії, а пороги налаштовуються за фактом, а не на око.
Технічні сумніви: хибні спрацювання, затримки, обходи
Хибні спрацювання — не властивість захисту, а наслідок порогів, виставлених на око. Тому правила спочатку йдуть у режимі спостереження: накопичуємо логи, розбираємо за ендпоінтами, додаємо винятки для колбеків платіжних систем, мобільних клієнтів і перевірок доступності. Блокування вмикається, лише коли хибних попадань у лозі не залишається.
Затримку визначає не фільтрація, а місце перевірки. Перевірку ботів ставимо на кешовані відповіді на краю, щоб до серверів доходив очищений трафік; для API залишаємо поведінковий аналіз без challenge. Час відповіді на 95-му процентилі заміряємо до і після — різниця зазвичай у межах похибки.
Що робити при зміні схеми розгортання?
Правила прив'язуємо до імен і міток, а не до адрес, тому при переїзді або додаванні балансувальника змінюється лише точка приймання трафіку. Порядок фіксуємо заздалегідь: піднімаємо новий контур, перевіряємо фільтрацію на тестовому потоці, потім перемикаємо бойовий.
Чи заважає захист захищеному каналу?
Ні: аналіз іде за метаданими з'єднання, вміст розбирається після термінації. Внутрішні виклики залишаємо на взаємній автентифікації — фільтр не блокує довірений трафік і не пропускає підміну.
Хто відповідає за пороги після передачі?
Налаштування передаємо з документацією: що за правило, на яку метрику реагує, що відбувається при спрацюванні та як відкотити. Далі пороги живуть у вашої команди, ми залишаємося на підтримці й переглядаємо правила при зростанні навантаження.
Обговоримо вашу задачу: що надіслати для оцінки та плану
Щоб оцінка й план впровадження спиралися на вашу інфраструктуру, а не на загальні міркування, вистачить кількох ввідних. За ними ми визначаємо точку фільтрації трафіку, режими роботи захисту та порядок вмикання без простою.
- Схема проходження трафіку. Де стоїть балансувальник, де розшифровується трафік, які канали та зовнішні точки входу задіяні. Від цього залежить, стає захист перед балансувальником чи після нього.
- Перелік сервісів на периметрі. Які застосунки та порти дивляться назовні, що критично, а що можна тимчасово закрити на час атаки.
- Історія інцидентів. Що вже відбувалося: сплески на каналі, флуд на прикладний рівень, спроби вичерпати з'єднання. Минулі атаки описують профіль трафіку точніше за будь-яку анкету.
- Вимоги до доступності. Допустимий час реакції, поведінка при хибних спрацюваннях, які легітимні джерела блокувати не можна — партнерські інтеграції, мобільні клієнти, офісні мережі.
- Очікуваний профіль навантаження. У скільки разів пік перевищує звичайний трафік, чи є сезонні сплески й разові події, до яких готуємося заздалегідь.
- Відповідальні на вашому боці. Хто дає доступи до панелі керування захистом і до доменних записів, хто погоджує вікно робіт і з ким ми ескалуємо вночі під час атаки.
З таким набором ми повертаємося з оцінкою та планом впровадження: де стає захист, які пороги виставляємо, як перевіряємо правила на живому трафіку і як відкочуємося однією правкою. Опишіть задачу захисту — далі уточнимо деталі питаннями.
