WAF на ModSecurity для корпоративного сайта: как мы спасли интернет-магазин от утечки 14 000 email клиентов

Привет! Меня зовут Семёнов Евгений Сергеевич, и я руковожу компанией АйТи Фреш. За мои пятнадцать лет в этой сфере я насмотрелся на десятки утечек клиентских баз. И знаете что? Почти все они происходили из-за одной и той же уязвимости: незащищённой веб-формы на сайте компании. В этой статье я хочу на конкретном примере показать вам, что такое WAF (Web Application Firewall), почему открытый ModSecurity — это идеальный вариант для большинства российских компаний, и как мы внедряли его для одного из наших клиентов в сфере e-commerce.

Почему обычный сайт оказывается беззащитным

Когда руководитель заявляет «у нас же SSL-сертификат стоит, мы защищены», я обычно молча открываю логи Nginx и показываю, сколько запросов вида ?id=1 UNION SELECT прилетает на их сайт ежедневно. У среднего корпоративного сайта это от тысячи до десятка тысяч подозрительных обращений в сутки. SSL шифрует канал — но он никак не фильтрует, что именно по этому каналу передаётся.

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

Так что же такое WAF, или Web Application Firewall? Представьте его как "умного" привратника, который стоит на страже между интернетом и вашим веб-сервером. Он скрупулёзно изучает каждый входящий HTTP-запрос: куда он направляется, что в себе несёт, выглядит ли он как обычный пользовательский трафик или как попытка взломать систему. Если запрос вызывает подозрения — WAF тут же его блокирует, не давая ему пройти дальше.

Кейс: интернет-магазин, который подвергся утечке клиентской базы

В феврале 2026 года к нам обратился руководитель одного интернет-магазина. Для удобства назовём его «МагазинОнлайн». Это довольно крепкий средний бизнес: у них ежедневно бывает по 15 000 уникальных посетителей, ассортимент насчитывает около 2 миллионов SKU, а в штате работает 28 человек. Но за месяц до того, как они пришли к нам, у них произошла настоящая катастрофа: кто-то через SQL-инъекцию в форме поиска товаров сумел вытянуть дамп таблицы с email-адресами 14 000 клиентов. Эти базы потом всплыли в спам-рассылках, клиенты были в ярости, звонили и возмущались, а репутация компании сильно пошатнулась.

Вот что мы увидели на аудите:

• Сайт работал на PHP 8.2 + Laravel, фронт через Nginx 1.24, база MySQL 8.0.
• Никакой защиты не было: ни WAF, ни ограничения на количество запросов с одного IP, ни блокировки сканеров.
• Логи за последнюю неделю показали 47 832 подозрительных обращения — это в среднем 4–6 атак в минуту.
• Топ-3 атакующих IP-адреса сделали по 6–13 тысяч запросов каждый и не были забанены.

Задача, на первый взгляд, казалась простой: нужно было внедрить защиту, которая эффективно отсекает все атаки, но при этом ни капельки не мешает живым покупателям. Бюджет был строго минимальный, а срок — всего две недели, потому что на носу была старт весенней распродажи. Идеальное решение напрашивалось само собой: ModSecurity в паре с набором правил OWASP Core Rule Set.

Почему именно ModSecurity, а не Cloudflare или AWS WAF

Когда речь о WAF, у бизнеса три класса решений: облачные (Cloudflare, AWS WAF, Imperva), коммерческие on-premise (FortiWeb, F5, ПТ AF от Positive Technologies) и open-source (ModSecurity, NAXSI). У каждого свои сильные стороны:

У «МагазинОнлайн» была своя специфика: они хранили данные банковских карт, работая через интеграцию с эквайрингом, и категорически не хотели пускать трафик через зарубежные CDN. К тому же, бюджета на дорогой ПТ AF у них просто не было. Вот почему ModSecurity подошёл идеально: это абсолютно бесплатное ПО, которое можно установить прямо на тот же сервер, где уже крутится Nginx, и самое главное — оно не требует перенаправлять трафик куда-либо на сторону.

Как мы разворачивали защиту: семь шагов вместо длинной портянки команд

Я не буду перегружать вас кодом в этой статье, лучше расскажу о самой логике работы. А если вам понадобятся технические тонкости, мои инженеры всегда готовы показать всё на нашем демо-стенде.

1. Поставили модуль ModSecurity на тот же сервер, где работал Nginx. Это безопаснее, чем выносить WAF на отдельный сервер: меньше точек отказа.
2. Подключили набор правил OWASP CRS. Это коллекция из примерно 200 правил против самых частых атак: SQL-инъекции, XSS, попытки прочитать /etc/passwd, обращения к админкам.
3. Включили режим наблюдения, а не блокировки. Первые семь дней WAF только записывал в лог подозрительные запросы, но ничего не блокировал. Мы посмотрели, какие правила срабатывают на легитимный трафик магазина.
4. Нашли и отключили ложные срабатывания. Например, в каталоге товаров была категория «etcetera» — правило WAF принимало это за попытку прочитать системные файлы. Создали исключение под URL каталога.
5. Включили блокировку. После того, как ложных срабатываний не осталось, перевели WAF из режима наблюдения в режим активной защиты.
6. Подружили с fail2ban. Если один IP-адрес делает больше десяти заблокированных запросов за пять минут — бан на час через iptables. Это разгружает WAF: повторные запросы атакующего не доходят даже до анализа.
7. Настроили уведомления в Telegram. Каждый бан и каждое срабатывание критичного правила приходит в чат службы безопасности.

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

Что получилось через месяц после запуска

Самая наглядная статистика — сравнение «было/стало» за тридцать дней работы:

За первые тридцать дней WAF успешно заблокировал около 84 000 атак и забанил больше трёх тысяч уникальных IP-адресов. Что важно, скорость загрузки сайта при этом совершенно не изменилась — покупатели вообще ничего не заметили! И самое главное: за прошедшие после этого два месяца не было ни одной успешной утечки, ни одного компрометирующего инцидента.

Подводные камни, о которых редко пишут

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

• Правила OWASP CRS нужно обновлять. Новые атаки появляются ежемесячно, и старые правила перестают работать. Минимум — раз в месяц git pull и проверка changelog. Критические обновления (свежие CVE) выходят чаще.
• Тюнинг — не разовая работа. Сайт меняется: появляются новые формы, разделы, интеграции. Каждое такое изменение может породить ложные срабатывания. Если их не лечить, маркетинг придёт с криком: «У нас не оформляются заказы!»
• WAF не заменяет правильно написанный код. Это слой защиты, а не индульгенция от безалаберности. Подготовленные SQL-запросы, экранирование вывода, валидация ввода — всё это по-прежнему обязанность разработчиков.
• Платёжные системы — отдельная история. Тинькофф, ЮКасса, СберPay шлют webhooks с большими JSON-пакетами, которые WAF может посчитать атакой. Их IP-диапазоны нужно добавить в исключения.
• Логи WAF растут быстро. При 30 000 атак в сутки лог-файл за неделю распухает до 2–3 ГБ. Нужна ротация и архивирование, иначе диск кончится в самый неподходящий момент.

Все эти потенциальные проблемы мы полностью закрываем нашей подпиской на абонентское обслуживание. Говоря простым языком: раз в неделю наш инженер внимательно просматривает дашборд WAF, своевременно обновляет правила, разбирается со всеми странными срабатываниями и отправляет клиенту короткий, но ёмкий отчёт.

Сколько стоит WAF под ключ для среднего бизнеса

Вопросы из серии «сколько это стоит» в общем виде мне, честно говоря, уже порядком надоели. Поэтому я лучше отвечу на примере конкретного кейса «МагазинОнлайн». Все суммы, которые я назову, актуальны на апрель 2026 года и указаны уже с НДС:

Итого, первичные работы по полному развёртыванию обошлись примерно в 61 000 руб. Это, по сути, разовые затраты. Дальше — небольшая ежемесячная абонентская плата за поддержание правил в актуальном состоянии. Просто для сравнения: лицензия Cloudflare Pro для сайта со средним трафиком будет стоить где-то 240–360 тыс. руб. в год, а ПТ AF — это уже от 850 тыс. рублей и выше.

Когда ModSecurity не подходит

Будем честны — есть сценарии, где ModSecurity не лучший выбор:

• Сайты с экстремальным трафиком. Если у вас 50 000+ запросов в секунду, ModSecurity начинает съедать заметную часть CPU. Тут уже стоит думать о NAXSI или о выносе WAF на CDN-уровень.
• Простой сайт-визитка без форм. Если на сайте только статичные страницы и одна форма обратной связи, достаточно правильной настройки Nginx, fail2ban и капчи. Тяжёлая артиллерия не нужна.
• Госкомпании с требованиями ФСТЭК. ModSecurity не сертифицирован, поэтому при формальных требованиях нужен ПТ AF или аналог.
• Команда без квалификации. WAF без специалиста, который умеет читать логи и править правила, через полгода превращается в пыль. Если внутри компании нет таких людей и нет договора на абонентку — ставить нельзя.

Что делать прямо сейчас, если у вас на сайте есть формы

Хочу дать вам небольшой, но очень полезный чек-лист — это всего пять шагов, которые любой руководитель сможет пройти за один вечер, чтобы понять, насколько на самом деле защищён его сайт.

1. Откройте Google Search Console или Яндекс.Вебмастер. Если там есть предупреждения о вредоносном коде или взломе — у вас уже проблема.
2. Попросите сисадмина или подрядчика показать логи веб-сервера за последние сутки. Если они не могут или говорят «у нас логи не хранятся» — это сигнал бедствия.
3. Уточните, стоит ли fail2ban или аналог. Если нет — ставьте немедленно, это бесплатная защита от перебора паролей.
4. Спросите, когда последний раз обновлялись CMS и плагины (WordPress, Bitrix, Tilda). Если ответ «не помню» — высокий риск.
5. Закажите внешний аудит. У нас в АйТи Фреш он бесплатный для новых клиентов в Москве и в радиусе 50 км от МКАД.

FAQ — частые вопросы перед заказом

Стоит ли ставить ModSecurity, если у меня небольшой корпоративный сайт-визитка?

Если на сайте только статика и контактная форма — нет, достаточно правильной настройки сервера и fail2ban. WAF нужен там, где есть динамика: личный кабинет, оформление заказа, форма поиска по базе, админка. Тогда ModSecurity действительно спасает.

Сколько стоит развернуть WAF под ключ?

В АйТи Фреш базовый аудит и развёртывание ModSecurity с OWASP CRS стоит от 38 000 руб. за один сайт, плюс две недели тюнинга против ложных срабатываний — 12 000 руб. сверху. Дальше — поддержка в рамках обычной абонентки.

WAF сильно тормозит сайт?

При уровне Paranoia 2 средний прирост задержки — 5–10 мс на запрос. Пользователи этого не замечают. Главный ресурс — CPU: при 1000 запросов в секунду уходит примерно 15 % одного ядра.

Зачем ModSecurity, если есть Cloudflare?

Cloudflare — отличное облачное решение, но он терминирует TLS у себя и видит весь ваш трафик. Для интернет-магазинов с платёжными данными или для компаний, которые не готовы пускать персональные данные через зарубежные CDN, ModSecurity на собственном сервере — единственный вариант.

Кто будет следить за WAF после установки?

Это самый важный вопрос. WAF без сопровождения через 3 месяца становится бесполезным: правила устаревают, появляются ложные срабатывания. У нас в АйТи Фреш WAF — часть подписки на абонентское обслуживание, инженер раз в неделю проверяет логи и обновляет CRS.