Настройка WAF для Битрикс: внешний экран веб-приложения поверх кода

WAF (Web Application Firewall) — это веб-фаервол, который стоит перед сайтом и проверяет каждый входящий запрос ещё до того, как он дойдёт до кода. Для 1С-Битрикс это внешний экран веб-приложения: дополнительный рубеж обороны поверх ядра и модулей. Пока обычный фаервол смотрит на сетевые порты и адреса, веб-фаервол разбирает содержимое HTTP-запросов — параметры форм, тело, заголовки, маршруты — и отсекает то, что похоже на атаку: инъекции, попытки выполнить чужой код, перебор паролей, обращения к уязвимым путям. Легитимный трафик идёт к сайту как обычно, а вредоносный отбивается на подступах и попадает в лог.

Ключевая ценность WAF в том, что он защищает там, где код ещё уязвим. Любой сайт на Битрикс — это ядро, набор модулей и кастомные доработки, в которых периодически находят дыры. Между публикацией уязвимости и выходом патча проходит время, и именно в этом окне сайты чаще всего пробивают: эксплойт уже в открытом доступе, а исправления ещё нет. Веб-фаервол закрывает это окно: правило, отсекающее конкретный вредоносный шаблон запроса, ставится за час и держит фронт, пока разработчики готовят аккуратное исправление. Этот приём называют виртуальным патчингом.

Из чего складывается настройка WAF

Мы строим защиту из двух рубежей, которые дополняют друг друга. Первый — Cloudflare WAF на периметре: облачный фильтр снимает массовый мусорный трафик, отсекает ботов и сканеры и применяет управляемые правила ещё до того, как запрос дойдёт до вашего сервера. Второй — ModSecurity с набором правил OWASP Core Rule Set, установленный на самом веб-сервере: он разбирает запросы детально и ловит точечные инъекции и эксплойты под конкретный сайт. Поверх стандартных правил мы пишем кастомные — под структуру URL, формы и админку Битрикс, чтобы экран отсекал атаки, но не мешал работе сайта.

Главные составляющие услуги:

• ModSecurity с OWASP CRS на сервере: базовый набор правил против инъекций и известных эксплойтов;
• Cloudflare WAF на периметре: облачная фильтрация трафика и отсев ботов до сервера;
• кастомные правила фильтрации под URL, формы и админку 1С-Битрикс;
• виртуальный патчинг — закрытие свежих уязвимостей правилом до выхода обновления;
• защита от классов атак из OWASP Top-10: инъекции, XSS, обход аутентификации и другие;
• логирование срабатываний, разбор ложных блокировок и тонкий тюнинг правил под трафик.

Защита от OWASP Top-10

OWASP Top-10 — это признанный в индустрии список самых распространённых и опасных классов уязвимостей веб-приложений. Набор правил OWASP CRS как раз и заточен под распознавание этих атак: SQL-инъекций, межсайтового скриптинга, инъекций команд, попыток обхода аутентификации, обращения к служебным файлам и других. Веб-фаервол ищет в запросах характерные шаблоны и аномалии, набирает балл подозрительности и блокирует запрос, когда тот переходит порог. Уровень строгости — так называемый уровень паранойи — мы подбираем под ваш сайт: чем он выше, тем больше ловится атак, но тем тщательнее нужно настраивать исключения, чтобы не задеть легитимных пользователей.

Почему важна тонкая настройка под Битрикс

Готовый набор правил, включённый в режиме блокировки без настройки, почти всегда начинает мешать работе сайта: блокирует загрузку файлов в админке, ломает визуальные редакторы, режет легитимные запросы форм и поиска. Это и есть ложные срабатывания — главная причина, по которой владельцы боятся ставить WAF. Поэтому мы никогда не включаем блокировку сразу. Сначала правила работают в режиме наблюдения: они только фиксируют срабатывания в логах, ничего не блокируя. Мы анализируем эти логи, находим легитимный трафик, который цепляется за правила, добавляем точечные исключения и поднимаем уровень фильтрации. И только когда боевой трафик проходит чисто, переводим правила в режим блокировки.

Важно понимать, что веб-фаервол — это дополнительный рубеж, а не замена нормальной разработке и проактивной защите. Он отбивает массовые атаки, отсекает сканеры и закрывает окно риска до выхода патчей, но критичные уязвимости в коде всё равно нужно устранять, а сайт — держать в обновлённом состоянии. WAF выигрывает время и снижает вероятность пробоя, работая в связке с чистым кодом, обновлениями и проактивной защитой Битрикс. Именно поэтому мы относимся к нему как к слою обороны поверх всего остального: он усиливает защиту там, где она нужна больше всего, и даёт владельцу сайта понятную картину того, какие атаки идут и как они отбиваются.

Поставить веб-фаервол сегодня кажется делом пары кликов: подключить облачный сервис, включить управляемые правила — и сайт как будто защищён. На бумаге это выглядит быстро и дёшево. Но на практике между «WAF включён» и «WAF реально защищает, не мешая работе» лежит большая дистанция. Включённый без настройки экран либо пропускает точечные атаки под конкретный Битрикс, либо начинает блокировать собственных пользователей и ломать админку. Ниже разбираем, чем тонко настроенный фаервол отличается от режима в один клик, какие задачи он решает и как мы строим защиту, чтобы она работала, а не создавала проблемы.

Почему сайт пробивают именно в окне между уязвимостью и патчем

Жизненный цикл уязвимости устроен так: исследователь находит дыру, информация о ней публикуется, появляется готовый эксплойт, и только потом выходит официальное обновление. Между публикацией и патчем проходят дни, а иногда и недели. Всё это время сайт с уязвимым модулем открыт: эксплойт уже гуляет по сети, его автоматически прогоняют по тысячам сайтов сканеры и эксплойт-киты. Если у вас популярный модуль или типовая сборка, ваш сайт окажется в этой выборке. Именно в этом окне происходит большинство пробоев — не потому, что владелец что-то сделал не так, а потому, что патча физически ещё нет.

Веб-фаервол меняет правила игры. Как только становится известен вредоносный шаблон запроса, мы пишем правило, которое его отсекает, и ставим его за час. Сайт оказывается прикрыт ещё до того, как разработчики выпустят обновление. Этот приём — виртуальный патчинг — превращает WAF из абстрактной галочки в реальный инструмент управления риском. Подробнее о системной защите ядра и модулей можно почитать в услуге настройки проактивной защиты Битрикс, которая работает в связке с внешним экраном.

Чем тонкая настройка отличается от режима в один клик

Облачный WAF в режиме по умолчанию — это усреднённые правила для абстрактного сайта. Они неплохо снимают массовый мусор, но не знают ничего про структуру вашего Битрикс: какие у вас URL, как устроены формы, что происходит в админке, какие плагины загружают файлы. Поэтому такой режим живёт в двух крайностях. Если поднять фильтрацию повыше, он начинает блокировать легитимные действия: загрузку картинок, работу визуального редактора, отправку длинных форм. Если опустить, чтобы не мешал, он пропускает именно те точечные инъекции, ради которых ставился.

Тонкая настройка снимает эту дилемму. Мы разбираем реальный трафик вашего сайта, отделяем легитимные паттерны от атак и настраиваем правила так, чтобы высокий уровень защиты не задевал рабочие сценарии. Сначала экран наблюдает и логирует, мы вычищаем ложные срабатывания, добавляем исключения под админку и редакторы Битрикс — и только потом включаем блокировку. В итоге фаервол отсекает атаки, но для ваших пользователей и редакторов остаётся невидимым.

Два рубежа: Cloudflare и ModSecurity

Мы намеренно не ограничиваемся одним инструментом. Cloudflare на периметре — это первый рубеж: он снимает массовый трафик, отсекает ботов, сканеры и переборы ещё до того, как запрос дойдёт до сервера, и разгружает инфраструктуру. ModSecurity с OWASP CRS на сервере — второй рубеж: он видит запрос детально, в контексте конкретного Битрикс, и ловит точечные инъекции и эксплойты, которые облачный фильтр пропускает как внешне безобидные. Вместе они дают глубину обороны: одно отсекает объём, другое ловит тонкие атаки.

Такая связка особенно важна, когда уязвимость уже эксплуатируют или сайт пытаются положить ботами. Если вы сталкивались с массовыми запросами и переборами, посмотрите смежную услугу защиты от DDoS и ботов — она усиливает периметровый рубеж и хорошо дополняет веб-фаервол на уровне трафика.

Когда хватит базового экрана, а когда нужен полный

Мы не уговариваем всех ставить максимальную конфигурацию. Если у сайта небольшой трафик, нет сложной кастомизации и нет острой истории с пробоями, иногда достаточно облачного рубежа с аккуратной настройкой базовых правил — это закрывает массовые атаки и отсев ботов. Полный экран из двух рубежей с виртуальным патчингом оправдан, когда сайт нагружен, содержит много кастомного кода или модулей, работает с деньгами и персональными данными, либо уже сталкивался с инцидентами. На бесплатном аудите периметра мы смотрим вашу инфраструктуру, трафик и историю и честно говорим, какой конфигурации достаточно, а не предлагаем максимум по умолчанию.

Отдельно стоит сказать про связь с устранением уязвимостей. WAF закрывает окно риска, но не лечит причину — дыру в коде. Поэтому правильная последовательность такая: внешний экран отбивает атаку и выигрывает время, а параллельно идёт защита и устранение уязвимостей в самом коде. Один инструмент без другого работает хуже: голый WAF оставляет уязвимость в коде, а починка кода без экрана не спасает в окне между публикацией дыры и патчем.

Как мы ведём работу

Старт — это аудит периметра. Мы смотрим, на каком хостинге и веб-сервере стоит сайт, какие версии Битрикс и модулей используются, есть ли уже какая-то защита, как выглядит обычный трафик и были ли инциденты. На основе этого собираем конфигурацию: один рубеж или два, какие правила CRS включить, какой уровень паранойи задать, какие кастомные правила написать под ваш Битрикс. Состав и стоимость фиксируем до начала работ.

Дальше ставим рубежи, не трогая код сайта: подключаем Cloudflare на периметре и ModSecurity с CRS на сервере. Настраиваем базовый набор правил и пишем кастомные под структуру URL, формы и админку. Запускаем всё в режиме наблюдения и несколько дней собираем логи на боевом трафике. Это критичный этап: именно здесь мы видим, какие легитимные запросы цепляются за правила, и аккуратно вычищаем ложные срабатывания, добавляя точечные исключения.

Когда боевой трафик проходит чисто, переводим правила в режим блокировки и поднимаем уровень фильтрации до безопасного для вашего сайта максимума. Настраиваем логирование и алерты по критичным срабатываниям, чтобы вы видели картину атак. По завершении передаём конфигурацию, правила и документацию — поддерживать защиту можно своими силами. Если нужно, берём сопровождение: следим за новыми уязвимостями ваших модулей и оперативно выпускаем виртуальные патчи.

Возражения, которые мы слышим чаще всего

«WAF будет тормозить сайт». На практике грамотно настроенный экран добавляет минимальную задержку, а облачный рубеж за счёт фильтрации мусора и кэширования нередко даже разгружает сервер. Тяжёлым становится не сам фаервол, а избыточно строгие правила без тюнинга, которые гоняют каждый запрос через сотни проверок. Мы подбираем набор правил под реальные угрозы вашего сайта, а не включаем всё подряд.

«У нас уже стоит проактивная защита Битрикс, зачем ещё WAF». Это разные слои. Проактивная защита работает внутри приложения и завязана на его логику, а веб-фаервол отсекает запрос ещё на подступах, до того как он дойдёт до кода. Вместе они дают глубину обороны: что-то отбивается на периметре, что-то — внутри. Один слой не отменяет другой, а усиливает.

«Поставим WAF и забудем про обновления». Так не работает. Экран снижает риск и закрывает окно между уязвимостью и патчем, но он не лечит дыры в коде и не отменяет гигиену: обновления, чистый код, разграничение прав. WAF — это страховка и запас времени, а не индульгенция на заброшенный сайт. Лучший результат даёт связка внешнего экрана с устранением уязвимостей и регулярным обновлением.

Логирование и видимость атак

Защита, которую не видно, плохо управляется. Поэтому отдельный блок работы — логирование срабатываний и видимость происходящего на периметре. Каждый заблокированный запрос попадает в лог: видно, какое правило сработало, по какому шаблону, с какого источника и куда был нацелен запрос. Из этих логов складывается картина атак: какие классы угроз идут на ваш сайт чаще всего, какие модули пытаются эксплуатировать, в какие часы растёт давление сканеров. Это не абстрактные графики, а основа для решений: где поднять уровень фильтрации, какое кастомное правило добавить, какую уязвимость закрыть виртуальным патчем в первую очередь.

По критичным срабатываниям мы настраиваем алерты, чтобы вы или ваш администратор узнавали об активной атаке сразу, а не постфактум. При необходимости логи WAF подключаются к вашей системе мониторинга, и тогда защита периметра встраивается в общую картину наблюдения за сайтом наравне с метриками сервера и приложения. Чем прозрачнее видимость, тем быстрее реакция на новую угрозу и тем меньше окно, в котором атака может что-то успеть.

Глубина обороны: почему важны несколько слоёв

В безопасности нет одного волшебного инструмента, который закрывает всё. Надёжность даёт глубина обороны — несколько независимых слоёв, каждый из которых ловит то, что пропустил предыдущий. Облачный рубеж снимает массовый мусор и ботов. Серверный ModSecurity ловит точечные инъекции под конкретный Битрикс. Проактивная защита внутри приложения отслеживает аномалии в его логике. Чистый код и обновления убирают сами уязвимости. Разграничение прав ограничивает урон, если что-то всё же пробивает. Веб-фаервол — это два важных слоя в этой обороне, но именно как часть системы он работает лучше всего.

Мы выстраиваем эти слои так, чтобы они не дублировали друг друга вхолостую и не конфликтовали. Например, нет смысла гонять один и тот же массовый мусорный трафик через тяжёлые серверные правила, если его уже отсёк облачный рубеж, — это только нагружает сервер. Поэтому распределяем нагрузку: периметр снимает объём, сервер ловит тонкие атаки, а приложение следит за своей логикой. Такая архитектура даёт и защиту, и скорость, и предсказуемое поведение под нагрузкой, что особенно важно для нагруженных интернет-магазинов и порталов.

Что вы получаете по итогу

На выходе у вас работающий внешний экран веб-приложения: два рубежа фильтрации, набор правил CRS и кастомных правил под Битрикс, защита от классов атак OWASP Top-10, настроенное логирование и виртуальный патчинг под новые угрозы. Атаки из открытого доступа отсекаются на подступах, мусорный и сканирующий трафик до сайта почти не доходит, а новые уязвимости закрываются правилом за час, не дожидаясь релиза патчей. И всё это — без правки кода сайта и без ложных блокировок собственных пользователей. Конфигурация, правила и документация остаются у вас, поэтому защита не привязана к подрядчику: развивать её сможет как наша команда, так и ваш администратор.

С чего начать

Начните с разговора. Расскажите, на каком хостинге стоит сайт, какой у него трафик и были ли инциденты — мы проведём бесплатный аудит периметра, покажем слабые места и предложим конфигурацию веб-фаервола под вашу задачу. По итогам аудита вы получите честную картину: какой защиты достаточно именно вам, какие уязвимости стоит закрыть виртуальным патчем в первую очередь и за какой срок мы выведем экран в боевой режим. Обсудим ваш проект — и поставим перед сайтом рубеж, который реально защищает, а не мешает работе.