У вас є вебзастосунок на VPS. У лозі доступу видно спроби входу на /wp-admin, запити з UNION SELECT у рядку запиту та рівний потік трафіку з діапазонів IP дата-центрів, яким нема чого робити на вашому сайті. Ви хочете відфільтрувати очевидне сміття, перш ніж воно дійде до застосунку.
Саме тут більшість людей уперше стикається з терміном WAF SaaS. Для багатьох читачів «WAF» і «Cloudflare» — те саме, бо Cloudflare трапився їм першим. Це не те саме. WAF SaaS — це категорія: доставлений із хмари брандмауер вебзастосунків, який перевіряє ваш HTTP-трафік на периферії провайдера, перш ніж передати його на ваш origin. Cloudflare — один із продуктів усередині цієї категорії.
У цій статті розбираємо, як працює WAF SaaS, скільки беруть великі провайдери, де він дає збій на практиці й коли власний WAF на Linux VPS виявляється кращим варіантом.
TL;DR
- WAF SaaS — це брандмауер вебзастосунків, який доставляють із хмари. Ви або пропускаєте трафік через провайдера, або прив'язуєте WAF до підтримуваного хмарного ресурсу; сервіс оцінює HTTP(S)-запити до того, як їх обробить захищений застосунок.
- Великі провайдери використовують три загальні схеми ціноутворення: тарифи за підпискою (Cloudflare і Sucuri), оплату за фактом використання (AWS WAF) і комерційні пропозиції через відділ продажів (Imperva і Fastly). Витрати за фактом використання зростають разом із кількістю оброблених запитів і підключеними опціями, тоді як підписки зазвичай передбачуваніші.
- Існує задокументована критика WAF SaaS, і нижче ми її розбираємо. Вона вказує на затримки, хибні спрацювання, непрозорі блокування та маршрутизацію даних через третю сторону.
- Самостійно розміщені WAF на VPS — цілком робочий варіант. SafeLine і BunkerWeb — два open source проєкти, які зараз набирають обертів. Вони працюють як зворотний проксі перед вашим застосунком.
- Відмова від WAF може бути обґрунтованим рішенням, якщо безпека застосунку зріла, поверхня атаки контрольована, моніторинг сильний, а залишковий ризик задокументований і прийнятий.
Як працює WAF SaaS
Запит до example.com спершу потрапляє на периферію провайдера, бо туди вказує ваш DNS. Прикордонний вузол термінує TLS, розбирає HTTP-запит, проганяє його через рушій правил і далі або передає на ваш origin, або блокує, або надсилає на перевірку (CAPTCHA, JavaScript-тест), або обмежує частоту запитів джерела. Якщо запит передано далі, застосунок бачить його так, ніби він прийшов з IP провайдера, а вихідний IP клієнта передається в заголовку на кшталт X-Forwarded-For чи CF-Connecting-IP.
Багато продуктів WAF SaaS використовують керований провайдером зворотний проксі або інтеграцію на периферії, але не кожен сервіс під'єднують через зміну DNS. Cloudflare, Sucuri і Fastly зазвичай стоять на шляху запиту, на периферії. AWS WAF натомість зв'язується з CloudFront або з підтримуваними ресурсами AWS такими як Application Load Balancer, API в API Gateway та API AppSync. У будь-якому разі HTTP(S)-запити оцінюються до того, як їх обробить захищений застосунок.
WAF аналізує дані сьомого рівня: заголовки запитів, шляхи, рядки запиту, методи, куки та налаштовану частину тіла запиту. Класичний мережевий екран ухвалює рішення переважно на рівнях 3 і 4, за адресами, протоколами й портами. Наш посібник «апаратний чи програмний міжмережевий екран» розбирає цю різницю ширше.
Керований захист WAF зазвичай спирається на три джерела правил:
- OWASP Core Rule Set (CRS) — це open source основа для ModSecurity і сумісних рушіїв WAF. Він покриває поширені категорії атак: SQL-ін'єкції, міжсайтовий скриптинг, ін'єкції команд і локальне підключення файлів. Продукти на базі ModSecurity часто постачаються з CRS, тоді як багато хмарних провайдерів натомість використовують власні керовані правила.
- Керовані вендором набори правил — це пропрієтарні правила, які провайдер підтримує в актуальному стані. Сюди належать «Managed Rules» у Cloudflare, «AWS Managed Rules» в AWS WAF і потік даних про загрози в Imperva.
- Власні правила — це ті, що ви пишете самі. «Блокувати запити до /admin не з цього діапазону IP», «обмежити /api/login до 5 запитів на хвилину з однієї IP».
Правило проти SQL-ін'єкцій може позначити знайомий шаблон на кшталт ' OR 1=1 -- у параметрі запиту або в тілі запиту. Це ловить ліниві сканування, але WAF усе одно може пропустити обфусковані корисні навантаження, логічні вразливості та шкідливі запити, схожі на звичайний трафік застосунку. Він оцінює спостережувані сигнали запиту, а не бізнес-намір.
Від чого це захищає, простими словами:
- Ін'єкційні атаки, корисне навантаження яких збігається з відомою сигнатурою
- Трафік ботів від відомих сканерів
- Прості схеми перебору паролів
- Об'ємний DDoS, якщо провайдер також займається очищенням трафіку від DDoS
- Прості зловживання API
Чого він не робить:
- Виправити ваш застосунок
- Замінити валідацію вхідних даних у вашому коді
- Зупинити атаки, які виглядають як звичайний трафік
Безпека застосунку так само народжується в самому застосунку. WAF піднімає підлогу проти масових і автоматизованих атак, але стелю задають безпечне написання коду, встановлення оновлень, авторизація, обробка вхідних даних, моніторинг і реагування на інциденти.
WAF SaaS проти локального пристрою і проти самостійного розміщення на VPS
У 2026 році поширені три моделі розгортання WAF: хмарний WAF SaaS (Cloudflare, AWS WAF, Fastly та інші), фізичні чи віртуальні пристрої (зокрема рішення F5 та Imperva) і самостійно розміщене ПЗ на VPS або на власному сервері.
Три моделі різняться за чотирма практичними питаннями: хто експлуатує шар інспекції, хто платить за потужності, хто налаштовує правила і що відбувається, коли WAF блокує те, чого блокувати не мав. Далі у статті ці чотири питання слугують рамкою порівняння.
Хмарний WAF SaaS
Ви пропускаєте трафік через периферію провайдера або прив'язуєте WAF до підтримуваного хмарного ресурсу. Провайдер обслуговує потужності інспекції та керовані оновлення, а ви обираєте правила, створюєте політики під конкретний застосунок і налаштовуєте винятки. Серед поширених варіантів — Cloudflare, AWS WAF, Imperva, Sucuri та Fastly.
Компроміс: потужності й експлуатація стають чужим клопотом. Але й кожен HTTP-запит при цьому йде через чужу інфраструктуру. Ваш HTTP-трафік проходить через інфраструктуру провайдера, а метадані запитів чи знайдені фрагменти корисного навантаження можуть потрапляти в логи, залежно від провайдера, продукту та налаштувань логування.
WAF у вигляді локального пристрою
Фізичний чи віртуальний пристрій стає в розрив мережевого шляху. Покупці — зазвичай організації з налагодженою службою мережевої безпеки, фіксованими вимогами до потужності, жорсткими правилами розгортання або вже усталеними відносинами з вендором. Потужності, оновлення, висока доступність і налаштування залишаються на боці замовника.
Для багатьох невеликих і середніх команд закупівля пристрою, фіксована потужність і експлуатаційні витрати роблять цей шлях найменш практичним. Він усе ж може підійти організаціям, яким потрібен шар керування всередині мережі й у яких є люди для його обслуговування.
Самостійно розміщений WAF на вашому VPS
Ви ставите WAF на Linux VPS, спрямовуєте туди DNS, і WAF стає зворотним проксі перед вашим застосунком. Ви його експлуатуєте. Ви його налаштовуєте. Ви ж заходите о другій ночі, коли оновлення керованих правил заблокувало легітимний запит і подзвонити більше нікому.
Два open source проєкти зараз на підйомі: SafeLine — open source WAF на рушії семантичного аналізу замість чистого зіставлення регулярних виразів, і BunkerWeb — WAF на базі NGINX, що постачається з ModSecurity. Їхні ліцензії, моделі розгортання та вимоги до ресурсів розбираємо нижче, у розділі про самостійне розміщення.
Компроміс тут зворотний порівняно з SaaS. Ви контролюєте шар інспекції, потужності, логи й налаштування. Це знижує залежність від стороннього WAF-провайдера, але трафік і далі несуть вищі мережі та хостинг-провайдери. Обмеження інфраструктури, смуга пропускання, оновлення та реагування на інциденти тепер ваш клопіт.
SaaS WAF проти самостійно розміщеного WAF на вашому VPS
Порівняльна таблиця нижче зосереджена на практичних відмінностях, які системним адміністраторам доведеться обслуговувати й закладати в бюджет.
| Критерії | Хмарний SaaS WAF | Самостійно розміщений WAF на VPS |
|---|---|---|
| Хто експлуатує шар інспекції | Провайдер, на периферії мережі | Ви, на своєму VPS |
| Хто платить за потужності | Провайдер, із перевиставленням вам за підпискою або за запит | Ви, фіксована вартість VPS |
| Хто налаштовує правила | Налаштовуєте ви; оновлення керованих правил постачає провайдер | Ви, від початку до кінця |
| Що робити при хибному спрацюванні | Налаштовувати правила та винятки в межах інструментів провайдера; ескалювати проблеми платформи | Відредагувати правило самому; перерозгорнути за хвилини |
| Маршрут даних | Запити проходять через інфраструктуру інспекції провайдера | Запити проходять через інфраструктуру, яку ви контролюєте, перш ніж дійти до origin |
| Як поводяться витрати під час сплеску трафіку | Компоненти з оплатою за фактом використання можуть зростати разом з обсягом запитів | Зазвичай передбачуваніше, але смуга пропускання й масштабування все одно можуть додати витрат |
| Навантаження на операції | Низьке, обмежене налаштуванням і тюнінгом | Ви обслуговуєте і VPS, і WAF |
Ціни на WAF SaaS у 2026 році
Ціноутворення WAF SaaS зазвичай поєднує тарифи за підпискою, плату за фактом використання або комерційні пропозиції. Публічні ціни не можна порівнювати напряму: кожен провайдер по-своєму пакує керовані правила, контроль ботів, логування, підтримку та захист від DDoS.
| Поставщик | Модель ціноутворення | Стартова ціна | Що входить у стартовий тариф | Примітки |
|---|---|---|---|---|
| Cloudflare | Тариф за підпискою | Безкоштовно; Pro 20 $/міс за річної оплати або 25 $/міс за помісячної; Business 200 $/міс за річної або 250 $/міс за помісячної | Free Managed Ruleset; ширші засоби керування залежать від платного тарифу | Перед купівлею перевірте актуальні правила, ліміти та включені функції безпеки |
| AWS WAF | За запит | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Правила, якими керуєте ви; AWS Managed Rules можна підключити як керовані групи правил | Додаткова потужність, інспекція тіла запиту, преміальні керовані групи, CAPTCHA, Challenge, Bot Control і Fraud Control можуть додати до рахунку |
| Imperva | Корпоративна пропозиція | Зв'яжіться з відділом продажів | Керовані правила, аналітика загроз і опції безпеки API | Немає безпосередньо зіставної публічної ціни на самообслуговуваний WAF |
| Sucuri Platform | Тариф за підпискою | Basic Firewall 9,99 $/міс; Basic Platform 229 $/рік | Тариф firewall: WAF/CDN; пакет Platform додає сканування й очищення | Окремий файрвол і річний пакет Platform — це різні продукти |
| Fastly | Через відділ продажів | Зв'яжіться з відділом продажів | Інспекція на периферії або розподілена, керовані правила та захист API | Немає безпосередньо зіставної публічної ціни на самообслуговуваний WAF |
AWS WAF публікує ціни за компонентами, а Cloudflare і Sucuri публікують ціни самообслуговуваних тарифів. Imperva та Fastly для зіставних WAF-пропозицій використовують ціни через відділ продажів.
Станом на 29 липня 2026 року: сторінка тарифів Cloudflare вказує Pro за 20 $ на місяць за річної оплати або 25 $ за помісячної, а Business за 200 $ на місяць за річної або 250 $ за помісячної. Сторінка цін на файрвол Sucuri lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from тарифів AWS WAF as of the same date.
Imperva і Fastly не публікують безпосередньо зіставних цін на самообслуговуваний WAF, тож вважайте обидва варіанти «зверніться у відділ продажів», а не покладайтеся на оцінки третіх сторін.
Сторінка цін AWS WAF вказує базові нарахування: 5 $ за web ACL на місяць, 1 $ за правило або групу правил на місяць і 0,60 $ за мільйон оброблених запитів. Додатково можуть тарифікуватися розширена потужність, глибша інспекція тіла запиту, дії CAPTCHA чи Challenge, преміальні керовані групи та захист від шахрайства чи ботів. Атакувальний трафік, отже, може збільшити рахунок, але наскільки — залежить від обсягу, тривалості та ввімкнених функцій. Правила за частотою захищають застосунок; уже оброблені WAF-запити безкоштовними вони не роблять.
Де WAF SaaS не дотягує
Хибні спрацювання — перше практичне обмеження. Легітимне завантаження файлу, виклик API чи надсилання форми можуть нагадувати шаблон атаки й запустити кероване правило. Далі оператору треба знайти спрацьоване правило, звузити його або додати виняток і переконатися, що цей виняток не створює ширшого обходу.
WAF ухвалюють рішення за сигналами запиту, а не за бізнес-наміром. Суворі правила можуть блокувати легітимний трафік; широкі винятки можуть послабити захист. Хмарні сервіси зазвичай дають журнали подій, перевизначення правил і власні відповіді, але доступна видимість і важелі налаштування залежать від тарифу та провайдера.
Порада професіонала. Нові або суттєво змінені правила запускайте в режимі виявлення чи підрахунку. Поспостерігайте за репрезентативним трафіком, протестуйте критичні й рідкісні сценарії, розберіть хибні спрацювання й додайте вузько окреслені винятки, і лише потім вмикайте блокування. Актуальний посібник із налаштування CRS рекомендує один-два тижні або доти, доки не пройдуть піковий трафік і всі критичні сценарії.
Друге обмеження — накладні витрати на продуктивність. Один бенчмарк ModSecurity 2023 року виміряв 9 462 завантаження невеликих файлів за 7,36 секунди з увімкненим CRS проти 4,55 секунди без нього. Пропускна здатність упала з 2 079 до 1 285 запитів на секунду, а пікове навантаження на CPU в nginx зросло з 8 % до 73 %. Це була одна конфігурація й один тип навантаження, тож сприймайте цифри як доказ того, що інспекція чогось коштує, а не як універсальний коефіцієнт для розрахунку потужності.
Третє обмеження — маршрут даних. Кожен HTTP-запит, включно з тілом, проходить через інфраструктуру провайдера. Для застосунків, що працюють із персональними даними, фінансовими операціями чи медичними відомостями, це конкретне питання суверенітету даних. Застосунку, розміщеному в ЄС і пропускаючому клієнтські запити через американського WAF-провайдера, доведеться пояснювати важчий аудиторський слід і підписати кілька додаткових договірних умов, на відміну від того самого застосунку із самостійно розміщеним зворотним проксі на VPS у тій самій юрисдикції.
Четверте обмеження — трудовитрати на налаштування. Складнощі налаштування WAF включають хибні спрацювання, обмежений контекст застосунку й правила, які мають встигати за частими змінами коду. Джерело — погляд вендора, але операційна картина реальна: команди або вкладаються в постійне налаштування, або залишають більше правил у режимі лише виявлення.
Та сама критика 2023 року стверджує, що WAF може перетворитися на театр безпеки, коли команди спираються на нього замість того, щоб полагодити застосунок. Аргумент найсильніший для команд зі зрілою безпекою застосунків: параметризований доступ до бази, надійна авторизація, регулярне сканування залежностей, незмінні розгортання та робочий моніторинг. У менш зрілих середовищах WAF усе ж здатен знизити вразливість до масових автоматичних сканувань. Обидва твердження можуть бути правильними водночас.
WAF — це один шар ешелонованого захисту. Він не заміняє безпеку застосунку, але й театром безпеки не є. Гранична користь від WAF для одних команд висока, для інших низька. Вирішує те, як влаштовано сам застосунок під ним.
Коли самостійне розміщення WAF має сенс
Самостійне розміщення виграє у трьох ситуаціях. І програє ще у трьох. Спершу про виграшні.
Самостійне розміщення виграє, коли внутрішні політики або вимоги суверенітету даних виключають інспекцію зовнішнім WAF SaaS-посередником, коли характер трафіку робить оплату за фактом використання менш вигідною, ніж утримання власної інфраструктури, і коли команда хоче прямого контролю над рішеннями про блокування та над виправленням хибних спрацювань.
Самостійне розміщення програє, коли немає операційних ресурсів, коли застосунок живе на керованій платформі, чия модель маршрутизації робить зовнішній проксі незручним, або коли безкоштовний тариф провайдера вже покриває потрібні механізми контролю меншою ціною складності.
Безкоштовний тариф Cloudflare може бути практичною відправною точкою для невеликих і середніх команд, які й так користуються його DNS чи CDN і приймають його модель інспекції трафіку. Самостійне розміщення стає привабливішим, коли маршрут даних, прямий контроль над правилами чи передбачувані витрати на інфраструктуру переважують бажання звести експлуатацію до мінімуму.
SafeLine і BunkerWeb
Є два open source WAF для самостійного розміщення, про які варто знати.
SafeLine поширюється за ліцензією GPL-3.0, розгортається через Docker Compose і побудований на семантичному аналізі, а не на чистому наборі правил CRS. Репозиторій SafeLine повідомляє про 71,65 % виявлення, 0,07 % хибних спрацювань і 99,45 % загальної точності в режимі Balance за власною оцінкою на 33 669 зразках. Це вимірювання мейнтейнерів проєкту, а не незалежний бенчмарк, і узагальнювати їх за межі цього набору не варто.
BunkerWeb поширюється за ліцензією AGPL-3.0 і використовує NGINX під капотом. Він інтегрує ModSecurity з OWASP Core Rule Set і підтримує кілька моделей розгортання, зокрема Linux, Docker, Swarm і Kubernetes.
Обидва проєкти рахуйте за виміряним обсягом запитів, увімкненими захистами, навантаженням на TLS і строком зберігання логів. Для малотрафікового розгортання SafeLine 2 vCPU і 4 ГБ RAM — консервативна відправна точка із запасом над мінімумом для встановлення. Актуальний посібник зі швидкого старту BunkerWeb рекомендує щонайменше 2 vCPU і 8 ГБ RAM для тестів або дуже невеликої кількості сервісів, і 4 vCPU з 16 ГБ RAM для продакшену, що захищає багато сервісів. Обсяг сховища залежить здебільшого від швидкості запису логів і строку зберігання: виміряйте його, а не обіцяйте фіксовану кількість місяців.
Порада професіонала. За можливості запускайте самостійно розміщений WAF у тому самому регіоні, де й origin застосунку. Віддалений проксі додає до кожного запиту міжрегіональний мережевий round trip і здатен непомітно погіршити затримки. Перед перемиканням на прод виміряйте наскрізний час відгуку з регіонів ваших користувачів.
WAF обслуговуєте ви, а отже, й інфраструктура під ним ваш клопіт: доступність, оновлення безпеки, TLS-сертифікати, резервні копії, ротація логів, моніторинг, запас потужності та відновлення. Перевіряйте поведінку при відмовах так само ретельно, як правила фільтрації, щоб WAF не став єдиною точкою відмови.
Фреймворк для прийняття рішень
Шляхів чотири: безкоштовний тариф Cloudflare, платний хмарний WAF SaaS, самостійно розміщений WAF на VPS і повна відмова від WAF. Умова, що обирає кожен із них, своя.
Обирайте безкоштовний хмарний тариф WAF, коли доступні керовані правила й ліміти відповідають ризику застосунку, модель маршрутизації даних прийнятна, а пріоритет — звести експлуатаційну роботу до мінімуму. Проженіть реальні сценарії користувачів, перш ніж вирішити, що налаштувань за замовчуванням досить.
Обирайте платний WAF SaaS, коли вам потрібно більше керованих правил, логування, власних механізмів контролю, захисту від ботів чи API, підтримки або потужності, ніж дає безкоштовний тариф. Порівнюйте точну матрицю функцій і лімітів, а не лише назву плану. AWS WAF найсильніший там, де застосунок уже використовує підтримувані ресурси AWS, а команда впевнено прогнозує покомпонентні витрати.
Обирайте самостійно розміщений WAF, коли виконуються перелічені вище умови і ваша команда здатна надійно експлуатувати проксі. SafeLine і BunkerWeb — два проєкти, які варто оцінити першими.
Відмова від WAF може бути обґрунтованим рішенням, коли безпека застосунку зріла, поверхня атаки свідомо обмежена, моніторинг сильний, а залишковий ризик задокументований і прийнятий. Але вона не має ставати вибором за замовчуванням лише тому, що фреймворк перевіряє вхідні дані.
Висновок
Обирайте WAF SaaS заради потужностей, якими керує провайдер, і менших експлуатаційних витрат. Обирайте самостійне розміщення заради прямого контролю, якщо команда здатна надійно експлуатувати проксі. В обох моделях: викочуйте правила поетапно, вимірюйте затримки й хибні спрацювання і тримайте безпеку застосунку на першому місці.
Якщо самостійне розміщення відповідає вашим вимогам, почніть із Linux VPS у тому самому регіоні, що й origin. Cloudzy також пропонує розгортання з маркетплейсу в один клік для SafeLine і для BunkerWeb, щоб ви могли почати тестування, не збираючи базовий стек руками.
Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.
Переглянути тарифи LinuxЧасті запитання
Що таке WAF як послуга?
WAF як послуга — це брандмауер вебзастосунків, який доставляють із хмари. Трафік потрапляє в сервіс через DNS чи маршрутизацію зворотного проксі, через інтеграцію на периферії або через прив'язку до підтримуваного хмарного ресурсу. Провайдер обслуговує потужності інспекції та керовані оновлення; ви обираєте політики, налаштовуєте винятки й додаєте правила під конкретний застосунок.
Cloudflare — це WAF?
Так. Cloudflare надає функції WAF у складі ширшої периферійної платформи, до якої входять також DNS, CDN і захист від DDoS. Безкоштовні тарифи отримують Cloudflare Free Managed Ruleset; ширші набори правил, засоби керування, аналітика та керування ботами залежать від обраного тарифу й доповнень.
Чи достатньо безкоштовного WAF від Cloudflare?
Залежить від поверхні атаки застосунку, від потрібних правил, від вимог до логування й зберігання, від контролю API чи ботів, від вимог до підтримки та від вашої терпимості до хибних спрацювань. Free Managed Ruleset може бути корисною базою, але автентифікація, платежі чи регульовані дані не відображаються автоматично на якийсь один платний тариф. Порівняйте поточні ліміти функцій і звірте їх зі своєю моделлю загроз.
У чому різниця між WAF і звичайним брандмауером?
Класичний мережевий екран фільтрує трафік переважно за даними третього й четвертого рівнів: адресами, протоколами та портами. WAF оцінює HTTP(S)-запити на сьомому рівні, включно з налаштованими заголовками, шляхами, параметрами та вмістом тіла. Сучасні продукти безпеки можуть розмивати ці межі, але два механізми лишаються взаємодоповнювальними, а не взаємозамінними.
Що таке WAAP і чим він відрізняється від WAF?
WAAP розшифровується як Web Application and API Protection. Це ширше за класичний WAF: вендори зазвичай поєднують правила WAF з виявленням або контролем API, керуванням ботами та захистом від DDoS і зловживань на рівні застосунку. Точний склад пакета відрізняється в різних провайдерів, тож WAAP не варто вважати стандартизованим набором функцій.
Чи потрібен мені WAF, якщо фреймворк уже перевіряє вхідні дані?
Не завжди. Засоби фреймворку знижують ризик, але покривають не всякий шаблон автоматизованих зловживань. Додавайте WAF лише тоді, коли він закриває конкретно названий ризик, що виправдовує його вартість і налаштування.
