Placitum — WAF для веб‑приложений и API

Защита приложений и API, которую не страшно включить

Placitum устанавливается перед сайтом, магазином, кабинетом или API и включается без риска: сначала наблюдает, потом блокирует — и по каждому решению показывает, кто решил, за что и на каком основании.

  • visibilityБез блокировок вслепую. Новые правила сначала смотрят на живой трафик и блокируют только по вашей команде.
  • timerМиллисекунды, не секунды. У каждой проверки есть лимит времени, и запрос не ждёт дольше него.
  • health_and_safetyСбой проверки не роняет сайт. Для каждого отказа заранее задано, что делать: пропустить запрос или закрыть.
  • manage_searchКаждое решение объяснимо. Кто заблокировал, за что и сколько очков — в одной карточке.
Событие безопасности 11d4ea9c-80b2-4c7e-9f01-6a5b4c3d2e10
Вердикт
заблокирован
Очки
25/ 20
Запрос
POST shop.example.com /api/orders
Тело
{"coupon": "SALE' OR 1=1 --"}
Клиент
203.0.113.77
быстрые проверки
IP фильтр чисто0.6 ms
глубокие проверки
Правила обработки трафика +254.1 ms
инъекция SQL в coupon +5 условие OR 1=1 +5 обрыв комментарием +5 ключевое слово SQL +5 не похож на браузер +5
Капча чисто1.2 ms
Счётчик чисто0.9 ms
по необходимости
Допуск по спецификации не понадобился: порог уже превышен
Заблокировано по правилам · клиент увидел страницу отказа · приложение запрос не получило
От чего защищает

Восемь угроз, от которых защищает Placitum

Под каждую — своя проверка со своими правилами. Включайте то, что нужно вашему бизнесу: выключенное не тратит ни ресурсов, ни времени на запрос.

bug_report

Инъекции и известные атаки

SQL‑инъекции, XSS, выход за пределы каталога, подделка серверных запросов
OWASP Core Rule Set — из коробки.

Правила OWASP Core Rule Set обновляются отдельно от сайта. Ложное срабатывание чинится исключением за минуты, а не выключением защиты.

OWASP CRSзапросы и ответы
smart_toy

Боты и парсеры

выкачивание каталога, цен, контента
Того, кто выкачивает каталог, выдаёт сумма.

Счётчик помнит, сколько объектов и данных унёс каждый адрес, сеть или сессия. По одному запросу парсера от покупателя не отличить — тысячу за минуту не спрятать.

поведениелимитыкапча при подозрении
password

Перебор паролей и захват аккаунтов

брутфорс, утёкшие пары логин‑пароль
Второй фактор перед приложением, которое менять не нужно.

Одноразовые коды, корпоративный каталог или список пользователей. Плюс капча при подозрении: «вы человек?» спрашиваем не у всех подряд, а только когда поведение даёт повод.

второй факторкапча
api

Злоупотребление API

лишние поля, чужие методы, кривые данные
Что не по контракту — то не запрос.

Спецификация OpenAPI становится правилом допуска: лишнее поле, незнакомый метод, строка вместо числа — отказ. Никаких догадок, только соответствие схеме.

OpenAPIJSON Schema
speed

Перегрузка и флуд

атаки на уровне приложения
Лимиты срабатывают в памяти узла защиты, до всех остальных проверок.

Частота запросов по адресу, сети или ключу с автоматическим баном. Запросы с известных вредоносных адресов не доходят даже до проверок — это самая дешёвая защита из всех.

лимиты частотыавтобан
public

Нежелательные регионы и сети

страны, хостинг‑провайдеры, анонимные сети
География и сети — одной строкой в списке правил.

Списки адресов, стран и сетей провайдеров пополняются на лету. Свои офисы, партнёры и мониторинг проходят мимо проверок целиком.

геосписки
visibility_off

Утечки в ответах

персональные данные, служебные заголовки
Проверяем не только что пришло, но и что уходит.

Ответ приложения проходит свою проверку: чувствительные фрагменты и служебные заголовки вырезаются или заменяются до того, как их увидит клиент.

ответы тожемаскирование
swap_calls

Атаки через WebSocket

чаты, торги, уведомления
Реальное время — тоже под защитой.

Каждое сообщение в живом соединении проверяется отдельно, в обе стороны. Опасное отбрасывается, остальное идёт без задержки.

WebSocketв обе стороны
Как это работает

Каждый запрос проходит несколько проверок. До приложения доходит только чистый трафик.

Клиент Узел защиты Быстрые проверки списки и лимиты — в памяти, за микросекунды Снимок запроса пароли и токены уже замаскированы Проверки и очки очки и порог, лимит времени Решение пропустить · страница отказа · капча запрос ответ Сервисы проверок — каждый отдельно, свои правила сначала быстрые адрес · регион · лимиты затем глубокие правила OWASP · капча · второй фактор · счётчик по необходимости контракт API · правка ответа на проверку вердикт Ваше приложение получает оригинал запроса — без правок и без добавок чистый трафик проверка ответа каждое решение Журнал событий и карточка в панели кто, за что, сколько очков, что было в запросе
Дешёвые проверки идут первыми и отсекают явное. Дорогие видят только то, что прошло дальше. Как только очки превысили порог, остальные не запускаются вовсе. В панели проверки называются инспекторами.
  1. Быстрые проверки. Списки и лимиты — в памяти узла защиты, за микросекунды. Явно плохое отсекается здесь и не тратит ничьё время.
  2. Снимок запроса. Заголовки, параметры и тело — уже с замаскированными паролями и токенами — уходят сервисам проверок.
  3. Проверки по очереди. Сначала лёгкие, потом глубокие. Очки превысили порог — остальные не запускаются.
  4. Решение. Пропустить, показать страницу отказа или отправить на капчу. Приложение видит только чистый трафик.
  5. Проверка ответа и запись. Ответ приложения проходит свою проверку. Каждое решение попадает в журнал с полным разбором.
Политика доступа

Офис, удалённые сотрудники, партнёры, интернет‑клиенты — у каждого свои правила

Правила задаются по источнику запроса и по разделу сайта. Для офиса набор проверок один, для публичного интернета — другой, и ни одно исключение не живёт в коде приложения.

Откуда пришлиКак опознаёмЧто происходит
Офисная сеть Адреса офисов и корпоративного VPN в доверенном списке Идут мимо проверок или по облегчённому набору — без капчи
Удалённые сотрудники Вход через корпоративный каталог или список пользователей, плюс одноразовый код Доступ только к нужным разделам, по группам. Сессию можно отозвать одним действием
Партнёры и интеграции Список адресов партнёра и контракт API Всё, что не по спецификации, — отказ. Лимит частоты, чтобы чужая ошибка не положила ваш сервис
Интернет‑клиенты Публичный интернет, никаких доверенных признаков Полный набор проверок: правила OWASP, счётчик поведения, капча при подозрении, лимиты
Нежелательные страны и сети География, хостинг‑провайдеры, известные плохие адреса Отказ выносится в памяти узла, до всех проверок

Удалённые сотрудники

  • check_circleВход перед приложением. Ваше приложение не переписывается: второй фактор добавляется снаружи, а внутрь уходит имя вошедшего.
  • check_circleСпособ входа выбираете вы. Одноразовый код из приложения‑аутентификатора, пароль против корпоративного каталога по LDAP или NTLM, собственный список учётных записей.
  • check_circleДоступ по группам. Бухгалтерия видит своё, разработка — своё. Права снимаются с группы, а не с каждого человека.
  • check_circleСессии под контролем. Срок жизни, отзыв, повторный вход по требованию — например, когда поведение стало подозрительным.

Сетевые ограничения

  • check_circleСписки адресов и подсетей. Разрешающие и запрещающие. Постоянные ведёте вы, динамические пополняются автоматически.
  • check_circleСтраны и провайдеры. Целые регионы и сети хостинга закрываются одной строкой.
  • check_circleЛимиты частоты. По адресу, сети или любому признаку запроса. Срабатывают до всех остальных проверок.
  • check_circleПо разделам. «Админка только из офиса», «API только партнёрам», «личный кабинет — всем, но со вторым фактором».
Боты и парсинг

Парсер не получает каталог. Покупатель не видит капчу.

Бота выдаёт не отдельный запрос, а поведение. Система собирает несколько признаков и отвечает соразмерно: сначала считает, потом спрашивает, потом закрывает дверь.

functions

Считаем, сколько унесли

По каждому адресу, сети и сессии — сколько карточек товара, страниц и мегабайт он получил. Тысяча карточек за минуту — не покупатель.

web

Смотрим, как ведёт себя браузер

Живой браузер подгружает картинки, стили и скрипты. Скрипт парсера — нет. Этот признак учитывается при решении, показывать ли капчу.

fingerprint

Спрашиваем только при подозрении

Капча появляется, когда поведение превысило порог, а не у всех подряд. Собственная капча без внешних сервисов либо Turnstile, reCAPTCHA, hCaptcha, SmartCaptcha.

block

Закрываем источник

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

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

Секреты не попадают ни в журналы, ни в ответы, ни к тем, кому не положено

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

password

Маскирование в журналах

Пароли, токены, номера карт и значения cookie заменяются до того, как запрос увидит хоть одна проверка. Встроенный список секретов дополняется вашим.

  • checkТри режима для каждого поля: сохранить как есть · заменить значение хешем · не сохранять вовсе
  • checkВ событии видно, что поле было — и что оно замаскировано
  • checkОригинал — отдельно, только по явному решению и со своим сроком хранения
find_replace

Маскирование ответов

То, что уходит клиенту, тоже правится: версии серверов и внутренние заголовки вырезаются, номера карт, телефоны и служебные идентификаторы в теле заменяются по шаблону.

  • checkПравила по коду ответа и типу содержимого: шаблон для JSON не трогает страницы
  • checkРаботает либо всегда, либо по сигналу другой проверки — подозрительному клиенту показываем меньше
  • checkРаботает и для сообщений WebSocket
inventory_2

Хранение под контролем

Срок хранения запросов задаёте вы: неделя, месяц, год. По истечении срока данные удаляются автоматически — и всё это время они лежат внутри вашего периметра.

  • checkСертификаты и ключи шифруются в браузере администратора — панель видит только шифртекст
  • checkСвой срок на каждый вид данных: заголовки дольше, тела короче
  • checkНи один байт трафика не уходит за пределы вашей инфраструктуры, если капча собственная
Для кого

Четыре ситуации, в которых защита окупается быстрее всего

shopping_cart

Интернет‑магазины и маркетплейсы

Парсеры цен и каталога, перебор промокодов, нагрузка в распродажу. Счётчик и лимиты видят тех, кто берёт слишком много, а покупатели защиту не замечают.

account_balance

Финтех и API‑продукты

Контракт API как правило допуска, второй фактор для кабинетов, журнал каждого решения — готовый материал для разбора инцидента и отчёта регулятору.

cloud

Внутренние системы и кабинеты

CRM, учёт, порталы для сотрудников: из офиса — свободно, с удалёнки — по второму фактору и группам, из интернета — никак. Без правок в самих системах.

forum

Медиа и сервисы реального времени

Чаты, трансляции, торги по WebSocket. Каждое сообщение проверяется отдельно, и задержка остаётся в пределах единиц миллисекунд.

Выгоды

Почему это выгодно, а не просто безопасно

receipt_long

Готовые доказательства для разбора

Каждое событие хранит вердикт, вклад каждой проверки и что было в запросе. Разбор инцидента — чтение карточки, а не раскопки логов.

payments

Ресурсы — только под нагруженное

Каждая проверка — отдельный сервис. Копии добавляются той проверке, которая упёрлась в потолок, а не всей системе сразу.

extension

Открытые стандарты, без привязки

OWASP CRS, OpenAPI, привычный синтаксис правил ModSecurity. Ваши правила и спецификации остаются вашими.

groups

Одна панель для безопасности и DevOps

Черновик, кнопка «Разослать» и индикатор того, где изменения ещё не применились. Плюс API для всего, что делает панель.

Команде

Всё, что нужно каждый день, — на первом экране

dnsМониторинг состояния
historyСобытия безопасности
policyИнспекторыexpand_less
Каталог
Правила обработки трафика
IP фильтр
Второй фактор
Капча
Допуск по спецификации
Счётчик
Классификатор
Правка ответов
Куки
Автодействия
tuneНастройкиexpand_more
account_treeСтруктураexpand_more
settingsКонфигурацияexpand_more
subjectЖурналы
swap_horizТрафик
ДокументацияЛицензия
monitoring
Видно всё сразу
Работают ли узлы, справляются ли проверки, применились ли изменения. Если узел перестал отвечать — это отдельное состояние на экране, а не «наверное, всё хорошо».
sync
Изменения — одной кнопкой
Правки копятся в черновике и расходятся по узлам по кнопке «Разослать». Индикатор наверху всегда показывает, где они ещё не применились.
edit_document
Редактор правил встроен
Подсветка, справка под курсором, разбор правила в понятную форму и замечания: что не загрузится и что можно проще.
history
Разбор инцидента за минуту
Фильтр по адресу, разделу, коду или проверке — и карточка с полной картиной: какая проверка решила, сколько очков, что было в запросе.
translate
Русский и английский, светлая и тёмная
Тема переключается и на этой странице — значок справа вверху.
Внедрение

Устанавливается за день. Живёт в вашем контуре.

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

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

Что нужно от вас

  • check_circleСервер или виртуальная машина под узел защиты. Для пилота — одна.
  • check_circleСертификаты для доменов, которые встанут под защиту.
  • check_circleПереключение трафика на узел — через DNS или ваш балансировщик.
  • check_circleДоступ к корпоративному каталогу, если нужен вход сотрудников.

Как живёт в проде

  • check_circleБез единой точки отказа. Узлов защиты столько, сколько нужно; в каждой зоне доступности свои узлы и свои сервисы проверок.
  • check_circleИзменения расходятся на все узлы. Настройки раздаются одной кнопкой, каждый узел подтверждает применение — видно, где оно ещё не прошло.
  • check_circleОбновления без остановки. Новые правила и новые проверки включаются на ходу, трафик не прерывается.
  • check_circleВписывается в ваш мониторинг. Метрики в формате Prometheus, события — в открытом хранилище, к которому подключаются ваши системы отчётности.

Так устроена промышленная установка. Установка из placitum-core сейчас поднимает один узел защиты — второй и третий в работе.

Сколько добавляет к запросуобычнохудший 1%
Проверка адреса0.6 ms2 ms
Три проверки параллельно1.2 ms5 ms
Итого1.8 ms7 ms

Расчёт для типового API‑маршрута из двух волн: ≈1 мс на волну на небольшой нагрузке, по замерам нагрузочных тестов; худший процент сложен с запасом. Лимит времени задаёте вы — и он не будет превышен, как бы ни повели себя проверки.

Как начать

Сами или вместе с нами — без риска для ваших клиентов

Оба пути начинаются с наблюдения: защита смотрит на живой трафик и ничего не блокирует, пока вы не скажете.

terminal Сами

Установить и включить

Установка из placitum-core собирает и поднимает весь контур на одной машине. Бесплатно для собственных нужд, пока нагрузка не выше 100 запросов в секунду; образовательным организациям — без порога.

handshake С нами

Пилот на вашем трафике

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

Как проходит пилот с нами

  1. 1 час

    Разговор

    Что защищаем: сайт, API, кабинеты. Что болит: боты, атаки, доступ сотрудников. Выбираем один‑два раздела для пилота.

  2. 1 день

    Стенд

    Узел защиты перед копией приложения или на части трафика. Сертификаты, разделы, первые проверки — в режиме наблюдения.

  3. 1–2 недели

    Наблюдение

    Проверки смотрят на живой трафик и ничего не блокируют. Копится картина: кто попал бы под блокировку и почему.

  4. встреча

    Разбор

    Показываем отчёт: атаки, боты, ложные срабатывания. Правим исключения вместе с вашей командой прямо в панели.

  5. по одной проверке

    Включение

    Блокировку включаете вы: сначала на одном разделе, потом шире. Каждый шаг обратим за минуту.

  6. передача

    Команда работает сама

    Обучение, доступ к панели и документации. Поддержка — по коммерческой лицензии.

summarize

Чем заканчивается пилот

Отчёт с цифрами за период наблюдения — и рекомендация, какие проверки включать первыми.

  • checkСколько атак и какого рода: инъекции, перебор, флуд
  • checkСколько ботов и что они пытались унести
  • checkСколько ложных срабатываний было до настройки исключений — и сколько осталось после
  • checkСколько миллисекунд защита добавила к вашим запросам на самом деле
  • checkИз каких сетей работают сотрудники и партнёры — основа для политики доступа
Важно: всё это время ваши клиенты работают как обычно. Наблюдение — не эксперимент над ними, а испытание для нас.
Лицензия и код

Исходный код открыт. Для своих проектов до 100 запросов в секунду — бесплатно.

Условия — как в лицензии, без мелкого шрифта. Ниже пересказ; обязывает только сам текст.

Бесплатно

Для собственных нужд, пока нагрузка на установку не превышает 100 запросов в секунду. Образовательным организациям любой страны — без ограничения нагрузки. Код можно изучать и менять в рамках того же использования.

По коммерческой лицензии

Нагрузка выше 100 запросов в секунду и услуги вокруг продукта для других: установка, настройка, обслуживание, поддержка, эксплуатация и защита продуктом как услуга.

Что остаётся на вас

Бесплатное использование — без поддержки, гарантий и ответственности и без лент: списки адресов и ботов и обновления правил вы ведёте сами. Лицензии на сторонние базы и компоненты — тоже ваши.

Главный текст — английский LICENSE.md, русский — перевод. Продукт нельзя распространять, перепродавать и выдавать за свой.

Дальше

Покажем на вашем трафике

Час разговора, день на стенд, одна‑две недели наблюдения — и вы видите настоящую картину атак и ботов раньше, чем принимаете решение.

Задачи

Девять задач, с которыми к нам приходят, и как они решаются

С такими задачами приходят заказчики: Wi‑Fi с авторизацией в аэропорту и на вокзале, кабинеты продавцов в онлайн‑торговле, API торговли автозапчастями, небольшие SaaS‑сервисы. У каждой — порядок действий и способ проверить результат; настройка занимает от двадцати минут до часа и делается в панели: правила живут рядом с разделом сайта, а не в коде приложения.

01 Доступ

Открыть API только партнёрам

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

  1. В разделе /api/partner — разрешающий список: адреса и подсети трёх партнёров. Всё остальное закрывается.
  2. Загружаете спецификацию OpenAPI. Запросы, которые ей не соответствуют, получают отказ.
  3. Лимит частоты на каждого партнёра отдельно — чужой цикл в коде не займёт весь ваш сервис.

Итог: чужие не проходят вовсе, свои — только по договорённому контракту и в пределах согласованной нагрузки.

Как это настроить: партнёрский APIarrow_forward
02 Доступ

Закрыть страну или сеть хостинга

Вы работаете в одной стране, а половина трафика — мусор из зарубежных дата‑центров. Платить за его обработку не хочется.

  1. В списке правил добавляете строку: страны и сети хостинг‑провайдеров — запретить.
  2. Выше ставите разрешающую строку для своих: мониторинг, платёжный шлюз, партнёры.
  3. Выбираете, что увидит отсечённый клиент: страницу отказа с вашим текстом или голый код ответа.

Итог: отказ выносится в памяти узла защиты за микросекунды, ещё до всех проверок. Мусорный трафик перестаёт стоить денег.

Как это настроить: списки и порядок строкarrow_forward
03 Доступ

Админку — только из офиса

Панель управления сайтом открыта всему интернету. Переделывать это в коде долго, а закрыть надо сегодня.

  1. В разделе /admin — разрешающий список офисных подсетей и корпоративного VPN.
  2. Для тех, кто работает из дома, — вход со вторым фактором вместо полного запрета.
  3. Доступ к разделам раздаёте по группам корпоративного каталога, а не по спискам людей.

Итог: из интернета админка не открывается вообще. Из офиса — как раньше. С удалёнки — по одноразовому коду.

Как это настроить: админкаarrow_forward
04 Поведение

Посчитать, кто выкачивает каталог

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

  1. Заводите счётчик: сколько карточек товара и мегабайт получил клиент за окно времени.
  2. Выбираете, по кому считать: адрес, сеть провайдера, сессия. Смена адреса не спасает — сеть остаётся.
  3. Назначаете реакцию по ступеням: сначала капча, при упорстве — отказ, дальше — бан адреса на срок.

Итог: покупатель, который смотрит десять товаров, не замечает ничего. Парсер, который берёт тысячу, упирается в стену на второй минуте.

Как это настроить: счётчик и корзиныarrow_forward
05 Внутренняя угроза

Увидеть сотрудника, который выгружает базу клиентов

У менеджера есть законный доступ к карточкам клиентов. Одна карточка в минуту — работа. Четыре тысячи за ночь — увольнение и разбирательство. Обычный WAF этого не видит: каждый запрос легален.

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

Итог: у службы безопасности есть не подозрение, а запись: кто, когда, что именно и сколько раз. С сохранёнными запросами как доказательством.

Как это настроить: счётчик и корзиныarrow_forward
Превышение нормы внимание
Сотрудник
i.petrov · отдел продаж
Когда
02:40 — 03:20, суббота
Что делал
карточки клиентов, постранично
Объём
4 218 карточек · 61 МБ
Норма роли
до 300 в день
Откуда
домашний адрес, не офис
Реакция
выгрузка закрыта запросы сохранены
06 Детект

Включить правила OWASP и не заблокировать своих клиентов

Главный вопрос к любому WAF: «а он не заблокирует моих клиентов?». Ответ — в том, как устроено решение. Блокирует не одно совпадение, а сумма очков.

Атака: попытка инъекции в параметре Запрос id=1' OR 1=1 -- Инъекция SQL в параметре +5 Обрыв запроса комментарием +5 Логическое условие OR 1=1 +5 Клиент не похож на браузер +5 20 из 20 порог достигнут Блокировка приложение запрос не увидит Легальный запрос: отзыв покупателя со словом «select» Запрос текст отзыва о товаре Ключевое слово SQL в тексте +5 Апостроф в тексте +3 8 из 20 до порога далеко Проходит отзыв опубликован
Одно совпадение почти никогда не блокирует. Блокирует набранная сумма — поэтому текст со словом «select» проходит, а настоящая инъекция добирает до порога за четыре признака сразу.

Что настраивается

  • check_circleПорог на каждом разделе свой. Строгий на форме оплаты, мягкий на блоге. Ниже порог — строже защита и больше поводов для разбора.
  • check_circleДва готовых набора правил. Обычный и строгий: строгий видит больше, но требует настройки исключений.
  • check_circleИсключения точечные. «Правило про кавычки не применяется к полю отзыва» — а не «выключим защиту от инъекций».

Почему это важно для бизнеса

  • check_circleМеньше ложных блокировок. Случайное совпадение — не приговор: нужен набор признаков.
  • check_circleПонятный разбор. В событии видно каждое сработавшее правило и его вклад. Претензию клиента закрываете за минуту.
  • check_circleПравила общие, а не наши. OWASP CRS — открытый набор, который используют по всему миру и который обновляется независимо от нас.
07 Утечки

Убрать персональные данные из ответов

Старый метод API отдаёт телефон и полный номер карты. Переписать его — квартал работы, а показывать эти данные нельзя уже сейчас.

  1. Задаёте шаблон: телефоны и номера карт в ответах заменяются на маскированный вид.
  2. Ограничиваете область: только ответы этого раздела и только формат JSON — страницы сайта правило не трогает.
  3. Заодно вырезаете служебные заголовки, по которым видно версии внутренних систем.

Итог: клиент видит замаскированные данные сегодня, а разработка переписывает метод спокойно и в своём темпе.

Как это настроить: маска и архивarrow_forward
08 Нагрузка

Пережить распродажу и не лечь от флуда

В «чёрную пятницу» нагрузка вырастет в десять раз — и вместе с честными покупателями придут те, кто хочет положить сайт или скупить весь товар скриптом.

  1. Лимит частоты на адрес и на сеть: обычный покупатель в него не упирается.
  2. Разрешающие правила для своих: мониторинг, платёжный шлюз, мобильное приложение.
  3. Отдельный, более строгий лимит на болезненные разделы: оформление заказа, применение промокода.
  4. Кто упорно бьётся в лимит — попадает в запрещающий список на время, автоматически.

Итог: приложение получает ровно ту нагрузку, которую вы для него рассчитали. Лишнее отсекается до того, как дойдёт до серверов.

Как это настроить: лимиты частоты и времениarrow_forward
09 Поведение

Поймать бота по пути через сайт, а не по одному запросу

Карты перебирают прямо на кассе, каталог выкачивают обходом всех ссылок подряд — и каждый запрос по отдельности безупречен. Отличает бота от покупателя путь: человек сначала смотрит витрину и только потом платит, а по невидимой ссылке не ходит никогда.

Узел защиты: бан подсети режет раньше всех проверок — на всех трёх разделах Витрина /catalog · /item/ · /order/ страница → +1 кредита в тело — скрытая ссылка‑приманка подозреваемым — капча Касса /api/orders нет кредита → отказ по очкам прошёл капчу → не судить пять провалов → бан подсети Ловушка /price-list/ — ссылка есть только в приманке адрес → в подозреваемые маркер honeypot в журнал клиенту — обычный 404 пятый провал заказа Кредит — корзина счётчика ключ — адрес, общая для витрины и кассы +1 за страницу проверка · −2 за заказ Подозреваемые — живой список, запись на пять минут пишут ловушка, выкачка и касса без витрины · читает капча: зовётся только для них
Разделы не знают друг о друге — связывает их общее состояние: кредит в корзине счётчика, живой список подозреваемых и бан подсети на узле защиты. Приложение не менялось: приманку вставляет правка ответов прямо в тело страницы.

Как это устроено

  1. Витрина копит кредит. Каждая открытая страница — плюс единица в корзину счётчика по адресу. Корзина общая: касса видит тот же счёт.
  2. Касса его тратит. Заказ снимает две единицы. Пришёл без кредита — сто очков и отказ по сумме; витрину не открывал вовсе — адрес уходит в список подозреваемых.
  3. Приманка без правки приложения. В каждую страницу витрины перед </body> вставляется скрытая ссылка на «прайс‑лист». Человек её не видит, обходчик идёт — и раздел‑ловушка молча пишет его в тот же список. В ответ — обычная 404.
  4. Капча — только подозреваемым. Она стоит на витрине и на кассе, но зовётся лишь для адресов из списка: остальные её не видят и за неё не платят. Прошёл проверку — касса пропускает даже без кредита.
  5. Перебор закрывает сеть. Пятый отказ приложения в заказе отправляет в бан весь анонс сети — узел защиты режет её раньше всех проверок.

Итог: ни одно правило не решает по одному запросу. Улика собирается в одном разделе, последствие наступает в другом, оправдаться можно в третьем. Покупатель не видит ни капчи, ни приманки.

Проверено автотестом: 29 шагов, шесть клиентов — от покупателя до осторожного кардера.

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

Ничего экзотического: nginx, PostgreSQL, ClickHouse, NATS — то, что давно работает в продакшене.

Мы не изобретали свой веб‑сервер, свою базу и свой формат правил. Взяли то, что годами работает под нагрузкой в тысячах компаний, и связали в систему, которую можно настраивать из одной панели.

Архитектура

Две плоскости: трафик и управление

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

Плоскость трафика: работает независимо от плоскости управления Сервисы проверок правила OWASP · адрес и регион · капча · второй фактор · счётчик · контракт API · правка ответа на проверку вердикт Клиент Узел защиты nginx + модуль WAF Ваше приложение запрос чистый трафик Плоскость управления и наблюдения — вне пути запроса правки разослать Панель React + Material Контроллер черновик и сборка PostgreSQL: настройки Шина NATS настройки и события ClickHouse события безопасности Архив S3 запросы со сроком хранения настройки события Эта плоскость может отказать: узлы продолжат работать по последним настройкам, а события догонят позже.
Настройки идут вниз, события — вверх, и ни то, ни другое не находится внутри обработки запроса. Поэтому обновление правил не требует перезапуска, а недоступность панели не влияет на клиентов.
Состав стека

Что внутри и почему именно это

ТехнологияРоль в системеПочему выбрана
nginx
+ собственный модуль
Принимает клиентский трафик, собирает решения проверок и применяет их Один из самых распространённых веб‑серверов в мире: проверен нагрузкой, знаком вашим администраторам, умеет всё, что вы уже от него ждёте. Модуль встроен в его событийный цикл и не блокирует обработку
NATS
и JetStream
Связь узлов с проверками, доставка настроек, поток событий Задержки в микросекундах, кластеризация из коробки, надёжная доставка для событий. Быстрее и проще в эксплуатации, чем классические брокеры очередей
ClickHouse Хранилище событий безопасности и журналов Миллиарды записей и поиск по ним за секунды. Дешёвое хранение за счёт сжатия — история за год стоит разумных денег
Redis Быстрое хранилище: тело запроса на время проверки, счётчики поведения Работает в памяти, стоит рядом с узлами. Данные живут секунды и удаляются вместе с запросом
PostgreSQL Конфигурация: серверы, разделы, правила, черновики изменений Промышленный стандарт для данных, которые нельзя потерять. Резервное копирование — вашими обычными средствами
S3‑совместимое хранилище Архив запросов после вердикта, со сроком хранения Облачное или развёрнутое у вас — на выбор. Удаление по сроку делает само хранилище
Coraza
и OWASP CRS 4
Движок сигнатурных правил и сам набор правил Совместим с ModSecurity: ваши существующие правила и знания переносятся. Набор правил открытый, обновляется мировым сообществом
Go Сервисы проверок Предсказуемая скорость, компактные контейнеры, простое обновление по одному сервису
Python
и языковая модель
Классификатор: оценивает серьёзность уязвимости по её текстовому описанию Зрелая экосистема машинного обучения. Работает в стороне от быстрых проверок и не задерживает запрос
React и Material Design Панель управления Привычный интерфейс, два языка и две темы, работает в любом современном браузере без установки
Prometheus Метрики для вашего мониторинга Стандарт де‑факто: подключается к тому, что у вас уже есть, без переходников
Контейнеры
Docker, Kubernetes
Поставка и обновление всех компонентов Разворачивается там же, где живёт остальная ваша инфраструктура. Секреты — штатными механизмами платформы
Устройство

Почему проверки вынесены наружу, а не встроены в веб‑сервер

Классический WAF — одна большая коробка: правила, движок и веб‑сервер живут вместе. Здесь веб‑сервер занимается трафиком, а думают отдельные сервисы. Разница видна в трёх местах.

Новая проверка не трогает веб‑сервер

Добавить вид защиты — значит развернуть ещё один сервис. Не собирать заново nginx, не перезапускать его, не согласовывать окно работ. Ваш парк узлов остаётся нетронутым.

Сбой ограничен одним сервисом

Тяжёлая проверка не может съесть память веб‑сервера или уронить его. На каждый случай — нет ответа, перегрузка, недоступность — заранее задано, что делать: пропустить или закрыть.

Масштабируется то, что нагружено

Если упирается только проверка по правилам, добавляют копии именно её. Узлы, база и остальные проверки не меняются — и вы не платите за простаивающие ресурсы.

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

Что это значит для тех, кто будет систему эксплуатировать

  • check_circleИзменения атомарны и подтверждаются. Настройки расходятся одной версией целиком; узел проверяет её и применяет, только если она корректна. Панель показывает, где применилось, а где нет.
  • check_circleОткат — это предыдущая версия. Не «вспомнить, что меняли», а вернуть настройки, которые работали.
  • check_circleСписки адресов обновляются без перезапуска. Автобан и новые списки попадают в память узлов на ходу.
  • check_circleКаждый компонент сообщает о себе. Узлы и проверки шлют сигнал о состоянии каждые несколько секунд. Пропавший сигнал — отдельное состояние на экране, а не пустая строка.
  • check_circleМетрики там, где вы привыкли. Решения, задержки, отказы проверок — в формате Prometheus, дальше в ваши дашборды и алерты.
  • check_circleСобытия доступны запросом. Хранилище открытое: ваши аналитики строят отчёты сами, не дожидаясь нас.
  • check_circleВсё, что делает панель, доступно через API. Разворачивание правил можно встроить в ваш конвейер поставки.
Безопасность самого контура

Кто что видит внутри системы

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

key

Секреты не проходят через панель

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

shield

Проверки не видят лишнего

Маскирование применяется до передачи данных проверкам. Сервис проверки видит, что поле было, но не его содержимое — и это фиксируется в событии.

gpp_good

Ответ проверки ограничен

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

Установка

Два пути: контейнеры одной командой или кластер по вашим правилам

Образы одни и те же. Docker Compose поднимает весь контур на одной машине — этого достаточно для пилота и небольшой установки. Kubernetes нужен там, где важны отказоустойчивость и автомасштабирование проверок. Ни в том, ни в другом случае на стороне вашего приложения ничего устанавливать не нужно.

deployed_code

Пилот — за день

Одна машина, одна команда, один ключ. Дальше — домен, сертификат и адрес приложения в панели.

lan

Продуктив — по ролям

Узлы защиты, шина, проверки и хранилища разводятся по машинам и зонам доступности. Масштабируется то, что нагружено.

home_storage

Всё в вашем контуре

Свои серверы или ваше облако. Наружу ничего не отправляется, доступ в интернет с узлов защиты не нужен.

Железо

Мощность считается от потока проверок, а не от числа запросов

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

Пилот: одна машина

Ресурсминимумс запасом
Ядра816
Память16 ГБ32 ГБ
Диск200 ГБ SSD500 ГБ NVMe
Сеть1 Гбит/с1 Гбит/с

Диск здесь уходит в основном на события безопасности: при полном журнале и боевом трафике двести гигабайт кончаются за несколько суток, поэтому на пилоте сразу задают срок хранения.

  • check_circleХватает до пятисот запросов в секунду на одном‑двух доменах: все компоненты на одном хосте.
  • check_circleДостаточно для наблюдения. Проверки смотрят на живой трафик и ничего не блокируют — этого хватает, чтобы увидеть картину атак и ложных срабатываний.
  • check_circleДостаточно для обучения команды: панель, события, разбор инцидента и порядок изменений — те же, что в продуктиве.
  • check_circleЧего не даёт — отказоустойчивости. Машина одна, и её перезагрузка прерывает трафик. Поэтому пилот ставят рядом с боевым путём, а не вместо него.

Продуктив: по ролям

РолькопийядерпамятидискаКак масштабируется
Узел защиты2+4–88 ГБ40 ГБПо клиентскому трафику и числу соединений
Шина сообщений34–68–16 ГБ200 ГБ NVMeПо потоку сообщений; три экземпляра ради кворума
Сервис проверкипо нагрузке1–21 ГБКопиями, по одной проверке за раз; линейно
Быстрое хранилище22–48 ГБПо размеру тел в полёте; по экземпляру на зону
Хранилище событий1–28–1632–64 ГБот 1 ТБ NVMeПо сроку хранения и доле журналируемого трафика
База настроек1 + реплика2–48 ГБ100 ГБ SSDНе растёт от трафика: только настройки и черновики
Панель и служебные248 ГБ40 ГБНе растёт от трафика; вне пути запроса
Архив запросоввнешний S3по сроку храненияПо доле удерживаемых запросов и сроку

Ориентир — до пяти тысяч запросов в секунду на маршрутах с двумя‑тремя проверками. Колонка «копий» — минимум ради отказоустойчивости, а не потолок. Шины именно три: на двух экземплярах потеря одного останавливает доставку настроек и журнал, хотя трафик продолжает обслуживаться.

Как пересчитать под свой трафик

  • check_circleКопии проверки = поток проверок ÷ 10 000. Одна копия держит десять тысяч проверок в секунду примерно на одном ядре, копии складываются линейно. Поток проверок — это запросы в секунду, умноженные на число проверок на маршруте.
  • check_circleЯдра под шину = сообщений в секунду ÷ 5 000. На запрос приходится по два сообщения на каждую проверку плюс событие журнала. Шина — единственный компонент, который видит весь этот поток целиком.
  • check_circleПамять узла защиты — по буферу ответа. Не число запросов, а предел буфера умноженный на число запросов в полёте. Проверка ответа по первым 64 килобайтам вместо целого тела снижает требование на порядок.
  • check_circleДиск под события: 60–100 ГБ в сутки на десять тысяч запросов в секунду при полном журнале — уже со сжатием. Журнал разрешённого трафика прореживается процентом, журнал блокировок — никогда.
  • check_circleДиск под архив запросов считается отдельно и растёт быстрее всего: те же десять тысяч запросов при удержании пятой части тел по 4 КБ — около 690 ГБ в сутки. Архив только заблокированного при доле блокировок в полпроцента — 17 ГБ.
  • check_circleЗадержка = число последовательных волн × ≈1 мс на небольшой нагрузке. Проверки одной волны идут параллельно и стоят как одна.

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

Операционная система

Обычный Linux и обычные контейнеры

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

ТребованиеЗначениеЗачем
Архитектураx86‑64 с поддержкой SSE 4.2Требование хранилища событий; образы поставляются под эту архитектуру
Ядро Linux5.10 и новееcgroup v2 — предсказуемые квоты процессора и памяти у контейнеров
Файловая системаext4 или XFS, локальный дискХранилище событий и шина пишут интенсивно; сетевые файловые системы под них не годятся
Подкачкавыключена на узлах защиты и хранилище событийСвоп в пути запроса даёт задержки в сотни миллисекунд
Синхронизация времениchrony или systemd‑timesyncdСрок действия cookie, одноразовые коды капчи, порядок событий в журнале
Docker24 и новее, Compose 2.20 и новееПрофили состава и ожидание готовности при запуске
Kubernetes1.27 и новееПри установке в кластер

Дистрибутив роли не играет: подходят Debian 12, Ubuntu 22.04 и 24.04, RHEL 9 и совместимые, Astra Linux 1.7 SE и новее, РЕД ОС 7.3 и новее. Windows и macOS — только для разработки: предсказуемых лимитов на них нет.

Что настроить на хосте

  • check_circleПредел открытых файлов и очередь соединений. Узлы защиты держат десятки тысяч соединений: 262 144 дескриптора и увеличенный somaxconn.
  • check_circleВременные файлы тела — в памяти. Отдельный tmpfs с пределом размера: иначе чтение крупного тела превращается в чтение с диска внутри обработки запроса.
  • check_circleПрозрачные огромные страницы выключить там, где стоит быстрое хранилище: их фоновая дефрагментация видна как всплески задержки.
  • check_circleИсходный адрес клиента должен доходить до узла. Если впереди свой балансировщик — PROXY protocol либо X‑Forwarded‑For с доверенным источником. Иначе все проверки по адресу, региону и поведению увидят один адрес на всех.

Чего не требуется

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

Весь контур одной командой

Установка из placitum-core идёт по шагам и останавливается на первом отказе: проверки, окружение, секреты, инфраструктура, схема базы, сборка компонентов из исходников и запуск. Готовых образов она не качает — собирает у себя.

git clone -b develop https://github.com/exemt/placitum-core.git
cd placitum-core
./install.sh check                   # Docker, Compose, openssl, место
./install.sh install
  1. Окружение. Файл .env заводится из примера. Порты и реквизиты проверяют сразу: потом их смена означает пересоздание контейнеров.
  2. Ключ контура и ключи подписи. Ключ контура один на установку: закрытую половину видят узел защиты и служба ключа, открытую — панель, поэтому сертификаты шифруются в браузере администратора.
  3. Панель и вход трафика. Панель — на порту 8080, трафик — на 80 и 443. Порты меняются в .env до установки.
  4. Первый маршрут. В панели заводятся домен, сертификат и адрес приложения. Проверки включаются в режиме наблюдения — блокировок нет.
  5. Сутки наблюдения и включение. Разбираются ложные срабатывания, затем блокировка включается по одной проверке за раз.

Перед выходом в продуктив

  • check_circleСменить пароли хранилищ. В примере окружения они стендовые. Порты базы, хранилища событий и быстрого хранилища установка наружу не публикует — так и оставить.
  • check_circleВключить TLS на узлах и признак Secure у cookie входа и капчи.
  • check_circleЗадать политику перезапуска. Иначе перезагрузка хоста оставит контур лежать.
  • check_circleРазвести роли по машинам. На одном хосте проверки конкурируют за процессор с хранилищем событий, а сбой хоста останавливает всё сразу.
Границы способа: Compose годится для пилота, демонстрации и небольшой установки, где допустимо окно на перезапуск. Как только нужны обновление без простоя и автомасштабирование проверок — Kubernetes; манифесты для него в работе.
Установка в Kubernetes · в работе

Раскладка по объектам кластера

Каждый компонент ложится на тот объект, который отвечает его природе: узлы защиты и хранилища именованы и имеют состояние, сервисы проверок безымянны и масштабируются свободно.

ОбъектЧто в нёмПочему так
StatefulSet
3 реплики
Узлы защитыИмя экземпляра становится именем узла в панели и в событиях; у каждого свой том состояния
StatefulSet
3 реплики
Шина сообщенийКворум и постоянные тома. На двух репликах потеря одной останавливает доставку настроек
Deployment + автомасштабированиеСервисы проверокНи адреса, ни балансировщика: копия подключается к шине и сама встаёт в общую очередь. Порог — по процессору
Deployment + ServiceПанель, поиск, справочники, формы входа и капчиПлоскость управления и страницы, которые открывает браузер клиента
StatefulSet с томомБаза настроек, хранилище событийДанные переживают перезапуск, тома именованные
Service типа LoadBalancerВход клиентского трафикаС сохранением исходного адреса клиента
SecretКлюч контура, ключи подписи, реквизиты архиваШтатный механизм платформы; закрытый ключ видят только узлы
PodDisruptionBudgetУзлы защиты и шинаЧтобы плановое обновление кластера не сняло кворум

Четыре вещи, на которых установка в кластер ломается чаще всего

person_pin_circle

Подменённый адрес клиента

Без сохранения исходного адреса на входе все проверки по адресу, региону, сети и поведению считают один адрес — адрес узла кластера.

memory

Тела на диске вместо памяти

Временный каталог должен быть томом в памяти с пределом размера. Иначе крупное тело читается с диска внутри обработки запроса.

hub

Шина без кворума

Три реплики и бюджет прерываний. Обновление кластера снимает экземпляры по одному — без бюджета оно снимет два сразу.

view_agenda

Общий пул узлов

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

Манифестов в поставке пока нет: раскладка выше описывает, как они устроены, и они в работе. Сегодня placitum-core поднимает контур в Docker Compose.

Сеть

Что и куда должно ходить

Наружу смотрит ровно одно — клиентский трафик на узлы защиты. Всё остальное живёт внутри контура; панель открывается администраторам по вашим правилам доступа.

ЧтопортКто обращаетсяНаружу
Клиентский трафик80, 443Клиенты → узлы защитыда
Панель и API8080Администраторы и ваш конвейер поставки → панельпо вашим правилам
Шина сообщений4222Узлы, проверки, служебные сервисынет
Состояние шины8222Ваш мониторингнет
Хранилище событий8123, 9000Панель, поиск, ваши отчётынет
База настроек5432Панельнет
Быстрое хранилище6379Узлы защиты и проверкинет
Архив запросов443 / 9000Узлы защиты, поиск по событиямнет
Формы входа и капчи8080Узел защиты (запрос изнутри)нет
ПриложениевашУзлы защиты → ваше приложениенет

Требование к задержке есть только у трёх связей: узлы защиты, сервисы проверок и быстрое хранилище должны стоять в одной зоне доступности. Панель, хранилище событий и архив к пути запроса не относятся, и их задержка значения не имеет.

Проверка

Как убедиться, что собрано целиком

./install.sh status                  # таблица сервисов
curl -fsS 127.0.0.1:8080/healthz     # панель и API
curl -si  127.0.0.1/                 # трафик через узел защиты

# после первого маршрута — заведомая атака: ожидается 403
curl -si "127.0.0.1/?id=1%20OR%201=1--"

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

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

Девять сценариев: что включить, что выставить и как проверить результат

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

Время у заголовка — сколько занимает сама настройка в панели, без периода наблюдения.
01 Первое включение: смотрим и ничего не блокируем правила OWASP пассивно · снимок в журнал · ноль отказов Пилот30 минут expand_more

Узел защиты уже стоит перед приложением, но трогать он пока ничего не должен. Нужна картина: кто попал бы под блокировку, за что и сколько таких запросов в сутки.

Что выставить
Маршрут / — весь сайт
Инспекторы запросазадать → правила обработки трафика, набор default, волна 0
Режим строкипассивный — инспектор отвечает и пишет в аудит, но не решает
Порог счётаwaf_score_deny = 0 — порог выключен
Дедлайн фазыwaf_deadline = 50ms — лимит времени: верхняя граница добавки к запросу
Сбои инспекциивсе пять классов waf_exceptionпропустить
Снимок запросазаголовки и аргументы целиком; в запись — 4 КБ
Архивпусто: на пилоте объекты в S3 не нужны
Порядок
  1. Заводите пространство, виртуальный сервер и маршрут /. Ваше приложение указываете защищаемым сервером — трафик пойдёт через узел.
  2. В «Инспекторы → Каталог» объявляете имя, например crs, на процессе правил обработки трафика с набором default.
  3. На маршруте добавляете строку crs и ставите режим пассивный.
  4. Порог — 0, дедлайн — 50ms, все классы сбоев — «пропустить». Ни одна ветка не может закончиться отказом.
  5. «Разослать» и «Издать конфигурацию». Для клиентов не меняется ничего.
Как проверить
  • check_circleВ «События безопасности» идут записи с вердиктом «пропущен» и набранными очками — это и есть будущие блокировки.
  • check_circleФильтр «очки ≥ 20» показывает, кто превысил бы порог. Строка раскрывается в карточку со списком сработавших правил и вкладом каждого.
  • check_circleЧерез неделю разбираете ложные срабатывания (сценарий «Ложное срабатывание»), меняете режим на «активный» и ставите порог 20.
infoТак и задумано: очки пассивного инспектора в сумму не попадают вовсе. На пилоте порог можно оставить любым — он всё равно не сработает.
Итог: включение защиты перестаёт быть прыжком в темноту. К моменту, когда режим меняется на активный, все ложные срабатывания уже разобраны на живом трафике.
arrow_backЗачем это бизнесу: включить правила OWASP и не заблокировать своих клиентов
02 Ложное срабатывание: разобрать и починить карточка события · точечное исключение · защита остаётся включённой Разбор5 минут expand_more

Клиент жалуется: отзыв о товаре не публикуется. В тексте отзыва слово «select» и апостроф — инспектор правил OWASP считает это попыткой инъекции. Выключать защиту от инъекций на всём сайте из‑за одного поля нельзя.

Что выставить
События безопасности
Фильтрпуть /review, вердикт «отказ», окно — последний час
Карточка событиясработавшие правила, вклад каждого в сумму, тело запроса — ровно то, что видел инспектор
Маршрут /review
Исключение в набореправило 942100 не применяется к полю review_text
Порог счёта30 вместо общих 20: раздел заведомо шумный
Правка набораредактор ModSecurity прямо в карточке: подсветка, замечания на полях, справка по слову под курсором
Раскатка«Разослать» — правка расходится по узлам защиты; релиз приложения не нужен
Порядок
  1. Находите событие по времени и пути. Карточка показывает не «сработал WAF», а перечень правил и вклад каждого в сумму.
  2. Видно, что порог набрался из двух признаков в тексте отзыва: лечится исключением, а не выключением защиты.
  3. Исключение задаёте точечно — конкретное правило к конкретному полю. Остальные правила на этом же поле продолжают работать.
  4. Правите в редакторе набора: панель замечаний внизу говорит, что не загрузится вовсе, а что загрузится и не сработает.
  5. «Разослать» — и через несколько секунд правка на всех узлах. Откат тем же движением.
Как проверить
  • check_circleТот же отзыв отправляется повторно — и публикуется.
  • check_circleНастоящая инъекция в том же поле по‑прежнему добирает до порога: снято одно правило, а не защита от инъекций.
  • check_circleВ журнале таких событий на этом разделе больше нет, а история правки осталась: что поменяли, когда и кто.
Итог: претензия клиента закрывается за минуты и без релиза приложения. Всё, что нужно для разбора, уже собрано в одной карточке.
arrow_backЗачем это бизнесу: включить правила OWASP и не заблокировать своих клиентов
03 Админка — только своим список адресов до шины · второй фактор для удалёнки · допуск по группам Доступ20 минут expand_more

Панель управления сайтом открыта всему интернету. Закрыть надо сегодня, менять код приложения некогда, а сотрудников из дома пускать всё равно нужно.

Что выставить
Данные
Набор адресов officeподсети офисов и корпоративного VPN
Маршрут /admin — локальный слой
Списокадрес клиента ∈ officeallow: мимо инспекции целиком
Маршрут /admin — инспекторы запроса
Второй факторпрофиль staff, волна 0, режим активный
Условие вызоваif $uri not ~ \.(js|css|png|svg)$ — на статике проверка входа не срабатывает
Источник входа«Вход через WAF», пароль проверяется по LDAP
Кука сессиисрок 8h, привязка к адресу, живой набор сессий включён
Допуск по группамgate.groups = admins, ops
Ответ отказазапись каталога 403-admin со своим текстом
Порядок
  1. В «Данные» заводите набор адресов office и складываете туда подсети офиса и VPN.
  2. В разделе входа — источник «Вход через WAF»: способ проверки пароля LDAP, своя форма входа, кука со сроком.
  3. Профиль проверки входа — в панели она называется калиткой — на этот источник; в нём группы каталога, которым открыт раздел.
  4. Объявляете инспектора gate-staff с этим профилем и ставите строкой на маршруте /admin.
  5. В локальном слое маршрута — разрешающая строка для office. Она уводит офис мимо всех проверок, а всех остальных оставляет калитке — проверке входа.
  6. «Разослать» канал входа и издать конфигурацию.
Как проверить
  • check_circleИз офисной подсети раздел открывается как раньше — в журнале запись с пометкой «мимо инспекции».
  • check_circleИз интернета — форма входа; после успешного входа в записи видно имя сотрудника, источник и что подпись проверена.
  • check_circleПользователь вне групп получает 403-admin, и причина видна в карточке события.
warningПорядок строк важен. Разрешающая строка стоит выше запрещающих: решает первая совпавшая сверху вниз. Адрес, попавший в оба набора, будет закрыт, если разрешение не поднять.
Итог: приложение не переписывали ни строчки, а админка перестала быть открытой. Сессия любого сотрудника снимается удалением одной строки из набора живых сессий.
arrow_backЗачем это бизнесу: админку — только из офиса
04 Форма входа: перебор и утёкшие пароли лимит с автобаном · нулевая волна по адресу · капча только на отправку Аккаунты25 минут expand_more

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

Что выставить
Данные
Живой набор bruteforceадреса, срок жизни записи 1h
Маршрут /login — локальный слой
Лимит по адресускорость 10/min, запас 20, считать requests, решение block
Автобанключ попадает в bruteforce, срок берётся у набора
Лимит по сессииключ — кука сессии, hash=md5 обязателен
Маршрут /login — инспекторы запроса
Адрес клиентанабор правил со списком bruteforce, волна 0, режим активный
Капчапрофиль login, волна 1, условие if $request_method = POST
Снимок запросатело 2 КБ; имя password — в списке «не снимать»
Ответ отказа429-slow со своей страницей и понятным текстом
Порядок
  1. Заводите живой набор адресов bruteforce со сроком 1h: в него будет складывать адреса автобан.
  2. В локальном слое маршрута — лимит по адресу с автобаном в этот набор. Он работает в памяти узла, до всякой шины.
  3. Инспектор адреса на нулевой волне видит bruteforce и закрывает забаненных раньше любой тяжёлой работы.
  4. Капчу зовёте условием только на POST: тот, кто просто открыл форму, её не увидит никогда.
  5. Имя password кладёте в «не снимать»: пароль не попадёт ни к инспекторам, ни в запись, ни в архив.
Как проверить
  • check_circleТридцать попыток подряд с одного адреса → 429-slow, а адрес появляется в наборе bruteforce.
  • check_circleСледующий запрос закрывается уже нулевой волной: в карточке события — «адрес клиента: отказ», остальные проверки не звали.
  • check_circleВ карточке события на месте пароля пусто, и это записано как факт, а не забыто.
warningПро hash=md5. Без этой галочки правило с ключом длиннее 255 байт — а JWT в куке именно такой — молча не срабатывает. С ней корзина занимает 32 байта, каким бы длинным ключ ни был.
Итог: перебор упирается в стену на десятой попытке, живой человек с забытым паролем — максимум в капчу, а пароль не оседает ни в одном вашем хранилище.
arrow_backОт какой угрозы — перебор паролей и захват аккаунтов
05 Партнёрский API строго по контракту список адресов · спецификация OpenAPI · свой лимит каждому партнёру API40 минут expand_more

Интеграционный API открыт трём партнёрам и никому больше. Партнёры периодически шлют мусор: лишнее поле, строку вместо числа, метод, которого в контракте нет. Их ошибки не должны ронять ваш сервис.

Что выставить
Данные
Набор адресов partnersподсети трёх партнёров
Файл спецификацииpartner-api.yaml, привязан к набору правил допуска
Маршрут /api/partner — локальный слой
Списокадрес ∈ partnerswave: запрос уходит инспекторам, остальной локальный слой не проверяется
Лимит частотыключ — адрес клиента, 50/s, запас 100, решение block
Маршрут /api/partner — инспекторы запроса
Допуск по спецификациинабор partner-api, волна 1, режим сначала пассивный
Снимок запросатело 64 КБ; waf_body_limit не меньше
Сбои инспекцииtimeout → отказать, bus → пропустить
Ответ отказа422-contract с публичной причиной: партнёр сам поймёт, что чинить
Порядок
  1. Разрешающей строкой оставляете в инспекции только partners: чужой адрес закрывается в памяти узла и до шины не доходит.
  2. Спецификацию заливаете в «Данные → Файлы» и привязываете к набору правил допуска.
  3. Первую неделю инспектор стоит пассивным: он пишет в аудит каждое несовпадение и никого не блокирует.
  4. Разбираете накопленный список вместе с партнёрами: часть чинится у них, часть — это отставшая спецификация, и чинится у вас.
  5. Меняете режим на активный. Лимит частоты у каждого партнёра свой, потому что ключ корзины — его адрес.
Как проверить
  • check_circleЗапрос с лишним полем в пассивном режиме — запись «пропущен» с пояснением инспектора, что именно не сошлось.
  • check_circleОн же в активном — 422-contract, и партнёр видит причину, не открывая тикет.
  • check_circle50 запросов в секунду от одного партнёра проходят, 500 упираются в лимит — и это не задевает двух других.
warningСпецификация — часть релиза. Инспектор ровно настолько хорош, насколько она свежа: отставшая на один релиз — это отказы живым клиентам. Поэтому активным его делают только после калибровки на живом трафике.
Итог: чужие не проходят вовсе, свои — только по договорённому контракту и в пределах согласованной нагрузки. Ошибка в коде партнёра не занимает ваш сервис целиком.
arrow_backЗачем это бизнесу: открыть API только партнёрам
06 Каталог перестают выкачивать счётчик на фазе ответа · корзины по адресу и сети · ступени вместо блокировки Боты45 минут expand_more

Конкурент снимает цены и описания. Каждый отдельный запрос честный: обычный браузерный заголовок, обычный путь. Сигнатуры такое не ловят — отличает покупателя от парсера только сумма унесённого.

Что выставить
Маршрут /product/ — фаза ответа
Снимок ответавключить: по умолчанию фаза ответа не снимает ничего, а мерить надо по ответу
Инспекторсчётчик catalog, режим активный
Удержаниеmonitor — ответ уходит клиенту сразу, замер идёт следом
Корзина cardsзаряд +1 на каждый отданный товар
Корзина bytesзаряд — размер тела ответа
Осиадрес и сеть провайдера: смена адреса внутри сети корзину не обнуляет
Маршрут /product/ — фаза запроса
Инспектортот же catalog, волна 0, режим активный
Ступень 1cards > 300score 40 и просьба к капче поднять строгость
Ступень 2cards > 800deny, адрес в набор scrapers, маркер scraper на запись
Приём просьбна маршруте разрешён отправитель catalog
Порог счётаwaf_score_deny = 60
Порядок
  1. На фазе ответа включаете снимок: без него счётчику нечего мерить — по умолчанию фаза ответа не снимает ничего.
  2. Заводите корзины: cards прибавляет единицу на каждый отданный товар, bytes — размер тела.
  3. Оси задаёте обе сразу — адрес и сеть провайдера. Ротация адресов внутри одной сети не помогает.
  4. На фазе запроса тот же инспектор судит по уровням: первая ступень добавляет очки и будит капчу, вторая отказывает и уводит адрес в набор.
  5. На маршруте разрешаете приём просьб от catalog — без правила приёма просьба останется только строкой в аудите.
Как проверить
  • check_circleОткрываете десяток карточек руками: не происходит ничего, а уровень корзины уже виден в карточке события.
  • check_circleСкрипт на тысячу карточек: на трёхсотой появляется капча, на восьмисотой — отказ и адрес в scrapers.
  • check_circleФильтр журнала по маркеру scraper собирает всю историю источника одной выборкой.
infoРеакция приходит на следующем запросе. Ответ, переполнивший корзину, уже отдан — так устроена сама модель, настройкой это не меняется. Поэтому порог ставят с запасом до той цифры, которую жалко.
Итог: покупатель, смотрящий десять товаров, не замечает ничего. Парсер, берущий тысячу, останавливается на второй минуте — и каждая ступень подъёма видна в журнале.
arrow_backЗачем это бизнесу: посчитать, кто выкачивает каталог
07 Пик распродажи без падения свои мимо проверок · лимиты по разделам · лимит времени как обещание Нагрузка20 минут expand_more

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

Что выставить
Виртуальный сервер — локальный слой
Разрешающие строкиадрес ∈ monitoring, payments, mobile-appallow
Общий лимитключ — адрес, 20/s, запас 40, считать requests
Маршруты /checkout и /promo
Строгий лимитключ — адрес, 2/s, запас 5, автобан flood на 15m
Лимит на волныключ — адрес, 10/s, считать waves — бережёт шину, а не приложение
Маршрут / — лимит времени
Дедлайн фазыwaf_deadline = 40ms на все волны запроса
Сбои инспекциина время пика timeoutпропустить
Ответ отказа429-busy с заголовком Retry-After
Порядок
  1. Разрешающие строки для своих ставите выше всех запретов: платёжный шлюз не должен упереться в лимит в самый неподходящий момент.
  2. Общий лимит вешаете на сервер, строгий — отдельными строками на болезненные разделы: оформление заказа и промокод.
  3. Отдельная строка считает waves, а не запросы: один клиентский запрос порождает восемь и более сообщений на шину, и без этого атака усиливается.
  4. Дедлайн 40ms фиксирует верхнюю границу добавки. Что делать с не уложившейся волной, решает маршрут, а не инспектор.
  5. На время пика timeout переводите в «пропустить»: мигнувшая проверка не должна ронять оформление заказа.
Как проверить
  • check_circleНагрузочный прогон: до 20/s с адреса проходит, выше — 429-busy, и приложение этого даже не замечает.
  • check_circleПод таблицей инспекторов стоит цена фазы: сколько волны просят и сколько им отпущено. Второе число — тот самый дедлайн.
  • check_circleНа страницах «Виртуальные серверы» и «Пути» виден темп запросов по каждому: сразу понятно, какой раздел упёрся первым.
warningДве строки — одна корзина. Лимиты с одинаковыми ключом, скоростью, запасом и предметом счёта модуль не различает: запрос, попавший в обе, начисляется дважды. Панель об этом предупреждает до рассылки.
Итог: приложение получает ровно ту нагрузку, на которую рассчитано. Лишнее отсекается в разделяемой памяти узла — до шины, до инспекторов и до ваших серверов.
arrow_backЗачем это бизнесу: пережить распродажу и не лечь от флуда
08 Персональные данные не попадают ни в ответ, ни в журнал маска до инспекторов · оригинал только в архив · правка ответа на лету Утечки35 минут expand_more

Старый метод API отдаёт телефон и полный номер карты. Переписать его — квартал работы, а показывать эти данные нельзя уже сейчас. И в журнале безопасности их тоже быть не должно.

Что выставить
Маршрут /api/v1/orders — снимок
Тело запросаснимать 16 КБ, в запись — 4 КБ
Маскироватьphone, card, email — имя остаётся, значение заменяется хешем
Не сниматьpassword, cvv — складывается со встроенным списком секретов
Только эти заголовкиcontent-type, user-agent, x-request-id
Архив
Тело запроса64 КБ, источник — оригинал, хранить 30d, исход — только отказ
Маска архивасвоя, отдельным списком: к оригиналу маски снимка не применялись
Маршрут /api/v1/orders — фаза ответа
Правка ответовнабор mask-pii: телефоны и номера карт в теле → маскированный вид
Условие вызоваif $content_type ~ application/json — страницы сайта правило не трогает
Отдатьwaf_send store — клиенту уходит правленое тело
Порядок
  1. В снимке маршрута перечисляете имена: что маскировать, а что не снимать вовсе. Запрет всегда сильнее разрешения.
  2. Маска применяется до инспекторов: они видят, что поле было, но не его содержимое, — и этот факт обязателен в записи события.
  3. Для разбора инцидентов архиву нужен оригинал: включаете источник «оригинал» и задаёте ему собственную маску.
  4. Исход — «только отказ»: пропущенные запросы в архив не пишутся, и лишнего чтения из обменника — хранилища тел на время проверки — нет.
  5. На фазе ответа ставите инспектор правки, а waf_send говорит отдавать клиенту правленое тело, а не оригинал.
Как проверить
  • check_circleВ ответе метода вместо телефона и номера карты — маскированный вид. Схема ответа не изменилась, потребители API продолжают работать.
  • check_circleКарточка события: на месте card хеш, и рядом пометка, что инспектор смотрел на замаскированное значение.
  • check_circleОбъект в архиве по номеру запроса открывается прямо из карточки: там оригинал, но со своей маской и сроком 30d.
Итог: показывать нельзя уже сегодня — и уже сегодня не показывается. Разработка переписывает метод в своём темпе, а служба безопасности всё равно получает материал для разбора.
arrow_backЗачем это бизнесу: убрать персональные данные из ответов
09 Витрина, касса и ловушка: бота выдаёт путь кредит в корзине счётчика · приманка правкой ответа · капча по списку · бан подсети Боты60 минут expand_more

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

Что выставить
Общее для трёх разделов
Корзина кредитасчётчик browse по адресу: ёмкость 20, утечка 0,03 %/с — единица живёт минуты
Подозреваемыеживой список, объявлен узлу; запись на 5 минут
Банживой список сетей, запись на 2 минуты; на сервере — проверка адреса по нему, отказ до волн
Витрина /catalog, /item/, /order/
Запроссчётчик front, волна 0; капча, волна 1, условие вызова: адрес в списке подозреваемых
Ответправка ответов, волна 0: перед </body> скрытая ссылка на /price-list/all.csv; счётчик, волна 1: страница — +1 кредита, карточки — в корзину выкачки
Выкачкакорзина за 60 % → адрес в подозреваемые, маркер harvester
Касса /api/orders
Запроскапча, волна 0, то же условие; счётчик till, волна 1
Нет кредитауровень ниже 8 %100 очков; порог раздела 100 — отказ по сумме
Витрину не открывалниже 1 % → адрес в подозреваемые, маркер funnel-skip
Ответзаказ 201−2 кредита; отказ 400 → провал; номер карты в JSON маскируется
Переборпровалы за 70 % → анонс сети в бан
Приём просьбсчётчик принимает «не судить» только от капчи: прошедшего проверку касса пропускает
Ловушка /price-list/
Автодействиябез условий: адрес в подозреваемые, маркер honeypot
Порядок
  1. Заводите два живых списка — подозреваемые и бан — и объявляете их узлу: по первому зовётся капча, по второму узел режет сеть.
  2. Объявляете три корзины счётчика и два профиля одного процесса: front для витрины, till для кассы. Корзины общие: ключ знает адрес, а не раздел.
  3. На витрине правка ответов вставляет приманку перед </body> — приложение не трогается.
  4. На кассе капча стоит волной раньше счётчика: иначе её просьба «не судить» до него не дойдёт.
  5. На ловушке — только автодействия. «Разослать» и «Издать конфигурацию».
Как проверить
  • check_circleТри страницы и заказ — проходит. Второй заказ сразу — отказ по сумме, а в списке подозреваемых вас нет.
  • check_circleЗапрос /price-list/all.csv — обычная 404, но адрес уже в списке, и витрина просит капчу.
  • check_circleПять заказов на несуществующий товар — в бане анонс вашей сети, отказ получает и соседний адрес из неё.
infoПорядок волн — не вкус. Просьба доходит только до тех, кого спросят позже. Поставьте счётчик на кассе раньше капчи — и прошедший проверку человек снова получит отказ за пустой кредит, хотя настройка будет выглядеть правильной.
Итог: бот выдаёт себя тем, чего не делает человек: платит, не глядя на витрину, выкачивает всё подряд, ходит по невидимым ссылкам. Покупатель не видит ни капчи, ни приманки.
arrow_backЗачем это бизнесу: поймать бота по пути через сайт

Настраивается ровно так же

  • checkЧат и торги на WebSocket. Рукопожатие проверяется как обычный запрос, а дальше те же правила работают на каждом кадре — в обе стороны.
  • checkСтраны и сети хостинга. Запрет по региону и номеру автономной системы выносится в памяти узла за микросекунды, до всех проверок. Задача «Закрыть страну или сеть хостинга»
  • checkСотрудник, выгружающий базу клиентов. Счётчик по имени вошедшего вместо адреса и норма на роль — каждый запрос легален, ловится только сумма. Задача «Увидеть сотрудника, который выгружает базу клиентов»
  • checkПереезд с другого WAF. Свои правила ModSecurity и спецификации переносятся как есть: формат общий, привязки к нам нет.
Что общего у этих сценариев: настройка живёт рядом с разделом сайта, а не в коде приложения; включается наблюдением, а блокировать начинает по вашей команде; каждое срабатывание раскрывается в карточку с разбором. Любой из этих сценариев откатывается за минуту — тем же движением, каким включался.
Нагрузочные тесты

Что измеряли и что сняли

Замеры на стенде разработки. Конфигурация стенда и метод приведены полностью: числа не переносятся на боевое железо напрямую, но их можно пересчитать. Прогоны 10 и 12 сентября 2026 года.

  • memoryОдна машина: 24 ядра, 16 ГБ. Docker Desktop, всё в контейнерах — защита, хранилища, шина и сам генератор нагрузки.
  • dnsТри узла защиты по 2 ядра за балансировщиком; сервисы проверок — по 2 ядра на копию.
  • memory_altУ каждой службы своя квота процессора и памяти — пределы в цифрах ниже это и есть.
  • boltСумма квот больше числа ядер. Контейнеры делят процессор, поэтому задержка здесь шумит сильнее, чем на выделенном железе.
Стенд

Конфигурация

Компоненткопийядер на копию
Узел защиты: nginx с модулем32
Балансировщик перед узлами16
Шина сообщений16
Проверка правил52
Проверка адреса82
Допуск по спецификации, счётчик, правка ответов, второй фактор, капчапо 22
Автодействия, классификаторпо 12
Служба живых списков14
Справочник сетей и регионов12
Защищаемое приложение, однопоточное12
Генератор нагрузки14

Памяти отведено по гигабайту на службу, кроме двух: у службы живых списков два гигабайта, у справочника сетей — четыре, там лежит полный каталог автономных систем на 660 тысяч подсетей.

Метод

Как снимали

  • check_circleСтупень — постоянный темп 12 секунд. Указанный темп — это потолок, а не факт: факт приведён отдельной колонкой.
  • check_circleКаждая точка — медиана трёх повторов. Разброс темпа между повторами до 3%, разброс задержки заметно больше.
  • check_circleСтупени меряются порознь, с паузой. Если гнать их лестницей подряд, поздние ступени наследуют состояние ранних и занижают результат.
  • check_circleСтупень чистая при трёх условиях: ни одного неожиданного кода ответа, ни одного отказа проверки, ни одного оборванного соединения.
Тест 1

Цепочка из десяти проверок подряд

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

план, rpsфакт, rpsp50p99не тот код
5004969 ms18 ms0
100099117 ms402 ms0
15001373402 ms994 ms0
20001336670 ms1330 ms0
250010901060 ms1740 ms0

До тысячи запросов в секунду план держится: 991 из 1000, медиана — 17 мс на десять последовательных проверок, но хвост на этой ступени уже 402 мс. Выше цепочка стоит и темпа: пик 1373, а на 2500 факт падает до 1090 — очередь растёт быстрее, чем стенд её разбирает. Отказов проверок, потерянных сообщений и неверных кодов ответа нет ни на одной ступени. Это худший случай по числу обменов: в боевой настройке проверок на маршруте две‑три, и часть из них идёт параллельно.

Тест 2

Тот же стенд без защиты

Тот же путь до того же приложения, защита на маршруте выключена. Нужен, чтобы отделить потолок полигона от потолка защиты.

план, rpsфакт, rpsp50p99не тот код
5004971 ms2 ms0
150014921 ms4 ms0
20001735157 ms967 ms0
30001588835 ms1510 ms0

Стенд упирается сам около 1735 запросов в секунду: дальше не пускают однопоточное тестовое приложение и генератор. Разница с первым тестом и есть цена десяти последовательных проверок на пике — около двадцати процентов темпа. До тысячи запросов в секунду цена по темпу нулевая.

Тест 3

Предел одной копии проверки

Та же цепочка из десяти вызовов, но все десять обслуживает одна копия сервиса проверки. Меряется поток проверок, а не запросов.

speed

10 000 проверок в секунду

Одна копия, без единой потери, при загрузке около половины отпущенного ей процессорного времени. Дальше упирается стенд, а не копия.

stacked_line_chart

Копии складываются линейно

Три копии втрое отодвинули порог, за которым начинаются потери. По пиковому темпу проверить не удалось: раньше упёрся сам стенд.

inbox

Запас на входе — по темпу

Прогон показал, что запас на приёме надо считать от темпа сообщений, а не от глубины очереди, которая за этим приёмом стоит. После пересчёта — ноль потерь на 75 810 сообщениях; до пересчёта на том же объёме терялось тридцать три.

Тест 4

Автоблокировка: как быстро закрывается адрес и сколько это стоит

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

От запроса до блокировки

Охват блокировкипервый отказвсе копии проверки
Адрес клиента11–14 ms37–52 ms
Подсеть клиента12–14 ms40–58 ms
Автономная система целиком12–16 ms39–45 ms

Стенд без нагрузки, восемь копий проверки адреса, пять проб на каждый охват. «Все копии» — это первый отказ плюс пятнадцать подряд отказанных запросов: отдельной задержки между копиями проверки измерить не удалось, эти миллисекунды — цена самого опроса. Объём записи на скорость не влияет: автономная система из 250 подсетей закрывается за те же 12–16 мс, что и один адрес.

Тысяча запросов в секунду на один маршрут

Охват блокировкифакт, rpsp50p99записей в секундуслужба списков
Адрес клиента9953 ms132 ms1 000147 МБ · 0,4 ядра
Подсеть клиента9974 ms576 ms653151 МБ · 0,4 ядра
Автономная система9983 ms18 ms41 152382 МБ · 2,2 ядра

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

Две тысячи запросов в секунду на один маршрут

Охват блокировкифакт, rpsp50p99записей в секундуслужба списков
Адрес клиента1232781 ms1370 ms1 251153 МБ · 0,5 ядра
Подсеть клиента1282756 ms1290 ms822156 МБ · 0,4 ядра
Автономная система1071904 ms1570 ms38 142552 МБ · 3,1 ядра

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

Тысяча запросов в секунду на маршрут — с любым охватом блокировки: медиана 3–4 мс, ноль отказов проверок, ноль потерянных записей — и это при шестнадцати проверках по спискам и новом бане на каждый запрос. На охвате «автономная система» тот же темп означает сорок тысяч записей в секунду: сотни подсетей на каждый запрос. Две тысячи стенд уже не отдаёт, и проверка адреса тут ни при чём — она отвечает за те же 2–3 мс; упираются балансировщик, шина и журнал. Ошибок нет ни на одной ступени: перегрузка выражается временем, а не потерями.

Память на записи в списках

Кто хранитна одну запись160 000 записей
Хранилище живых списков≈190 Б30 МБ
Служба живых списков≈0,5 КБ+84 МБ
Копия проверки адреса≈70 Б+11 МБ

Постоянные списки лежат в памяти проверки адреса и приезжают к ней вместе с версией настроек; живые — ещё и в службе списков с её хранилищем. Под нагрузкой память службы определяется темпом записи, а не размером списков: на сорока тысячах записей в секунду она держится около 400 МБ из двух отведённых гигабайт, при том что в самих списках лежит вчетверо меньше записей, чем проходит за минуту. Узлы защиты к этим спискам не подключались — блокировку выносила проверка адреса.

Что это значит при расчёте. Список на миллион адресов — это около 190 МБ в хранилище и по 70 МБ в каждой копии проверки адреса, а первый отказ после блокировки наступает через 11–16 миллисекунд, на всех восьми копиях проверки адреса — через 37–58. Запас считается в записях в секунду: охват «адрес» и «подсеть» — одна запись на запрос, охват «автономная система» — сотни. Служба живых списков — один процесс, и её потолок на четырёх ядрах составляет около сорока тысяч записей в секунду. Важно, что происходит на потолке: она отвечает писателю отказом сразу, а не копит очередь, — бан, который не записался, виден как отказ в журнале, а не теряется молча.

Пределы

Практический и теоретический

Практический: снято

  • check_circle10 000 проверок в секунду на одну копию сервиса проверки.
  • check_circleПорог потерь растёт линейно от копий — проверено втрое.
  • check_circle1373 запроса в секунду на маршруте с десятью последовательными проверками против 1735 на том же стенде с выключенной защитой.
  • check_circleПервый отказ после блокировки — через 11–16 мс от запроса, который её поставил; на всех восьми копиях проверки адреса — через 37–58 мс.
  • check_circle40 000 записей в секунду в живые списки — два ядра и 380 МБ у службы списков; тысяча записей в секунду стоит ей 0,4 ядра и 150 МБ.

Теоретический: пересчёт

  • check_circleПоток = копии × 10 000 проверок в секунду. Нужно больше — добавляется копия.
  • check_circleЗадержка = число последовательных волн × ≈1 ms на небольшой нагрузке; с ростом очереди множитель растёт. Проверки одной волны идут параллельно и стоят как одна.
  • check_circleТиповой маршрут — две волны: адрес, затем правила. Порядка двух миллисекунд к запросу на небольшой нагрузке.
  • check_circleЗапас автоблокировки — в записях в секунду, а не в запросах: охват «адрес» и «подсеть» — одна запись на запрос, охват «автономная система» — около шестисот.
  • check_circleПамять списков: ≈190 Б на запись в хранилище и ≈70 Б в каждой копии проверки адреса.
Развитие продукта

Что работает сейчас и что выйдет в следующих выпусках

Выпуски раз в квартал. Обновление устанавливается без остановки трафика: новые проверки и правила включаются на ходу, а старые настройки продолжают работать.

  1. 1.1.25III квартал 2026

    Текущая версия

    выпущено
    • checkПравила OWASP CRS 4 со встроенным редактором, исключениями и двумя уровнями строгости.
    • checkВторой фактор и капча: одноразовые коды, корпоративный каталог, доступ по группам, капча при подозрении.
    • checkДопуск по спецификации и счётчик поведения: контракт API как правило допуска и защита от парсинга.
    • checkПроверка ответов и WebSocket: правка того, что уходит клиенту, и вердикт по каждому сообщению.
    • checkПанель, события и режим наблюдения: разбор любого решения и безопасная выкатка правил.
  2. 1.2IV квартал 2026

    Интеграция с процессами безопасности

    в работе
    • checkВыгрузка событий в SIEM. Отдельный канал в вашу систему сбора событий, со своим сроком хранения и своим форматом. Обработку запросов это не затрагивает: если приёмник недоступен, трафик идёт как шёл.
    • checkРоли и права в панели. Кто меняет правила, кто только смотрит, кто разбирает инциденты. Разделение обязанностей для аудита.
    • checkЖурнал действий операторов. Кто, что и когда изменил, с возможностью вернуться к предыдущей версии настроек.
    • checkУведомления по правилу. Всплеск блокировок, новая атака, пропавший с радара узел — в почту, мессенджер или систему оповещения дежурных.
  3. 1.3I квартал 2027

    Проверка загружаемых файлов

    запланировано
    • checkШлюз ICAP. Файлы, которые пользователи загружают на сайт, уходят на антивирус вашего вендора по стандартному протоколу. Заражённое до приложения не доходит.
    • checkКарантин вместо слепой блокировки. Крупная загрузка удерживается до вердикта антивируса, а не отклоняется по таймауту.
    • checkТип файла по содержимому. Исполняемый файл, переименованный в картинку, распознаётся по содержимому, а не по расширению.
  4. 1.4II квартал 2027

    Приватность данных

    запланировано
    • checkПравила маскирования по структуре документа. Не «замени всё похожее на телефон», а «поле client.phone в этом методе».
    • checkШифрование сохранённых запросов с автоматической сменой ключей. Для тех, кому это нужно по требованиям регулятора.
  5. 1.5III квартал 2027

    Новые протоколы

    запланировано
    • checkHTTP/3 и QUIC. Быстрый протокол современных браузеров — под той же защитой и с теми же правилами.
    • checkgRPC по сообщениям. Вердикт по каждому вызову внутри соединения, как это уже работает для WebSocket. Актуально для микросервисов и мобильных приложений.
    • checkПотоковые уведомления. Проверка событий, которые сервер шлёт клиенту непрерывно: биржевые сводки, статусы заказов, ленты.
  6. 1.6IV квартал 2027

    Меньше ручной работы

    запланировано
    • checkВнешние ленты угроз. Списки вредоносных адресов от поставщиков и из ваших источников, с обновлением по расписанию и без перезапуска.
    • checkСертификаты без ручной работы. Выпуск и продление по стандарту ACME: и публичные, и от корпоративного центра сертификации. Забытый сертификат перестаёт быть причиной простоя.
    • checkОбщая репутация источников. То, что узнал один контур защиты, учитывают остальные: адрес, забаненный на сайте, встречает закрытую дверь и в мобильном API.
  7. 1.7I квартал 2028

    Отчётность и платформа

    запланировано
    • checkОтчёты для руководства и регуляторов. Сводка за период по расписанию: что отбили, кого заблокировали, сколько ложных срабатываний.
    • checkПесочница правил. Прогнать новое правило на записанном за неделю трафике и увидеть, кого бы оно задело, не выпуская его в бой.
    • checkРабота в Kubernetes как ingress. Узлы защиты становятся точкой входа кластера, а настройки доставляются вашим обычным способом.