У вас есть веб-приложение на 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 только тогда, когда он закрывает конкретно названный риск, оправдывающий его стоимость и настройку.
