OpenAppSec: open-source WAF на базе машинного обучения для локальной защиты веб-сервисов
Пока внимание многих специалистов сосредоточено на инструментах автоматизированного пентеста и ИИ, вопрос защиты веб-приложений никуда не исчезает. Чем быстрее появляются новые сервисы и API, тем важнее фильтровать вредоносные запросы ещё до того, как они попадут в приложение.
Одним из интересных решений для этой задачи стал open-appsec - межсетевой экран веб-приложений с открытым исходным кодом. Он использует машинное обучение, умеет работать с веб-сервисами и API и не требует обязательного подключения к облачной платформе. Для домашней лаборатории, тестового стенда или небольшого продакшена это может быть привлекательной альтернативой тяжёлым коммерческим комплексам.
Что представляет собой open-appsec
Проект создавался при участии Check Point, а позднее был разделён на две ветки: открытую community-версию open-appsec и коммерческие продукты компании. При этом локальная установка позволяет собрать полностью автономный стек без передачи трафика во внешний SaaS.
В тестовой конфигурации можно использовать связку:
- Nginx Proxy Manager в роли обратного прокси;
- open-appsec для анализа и блокировки запросов;
- OWASP Juice Shop как намеренно уязвимое приложение для проверки защиты.
Подобная схема подходит не только для экспериментов. Её можно применять перед внутренними панелями, API, self-hosted-сервисами и небольшими публичными сайтами.
Как работает агент
Несмотря на использование машинного обучения, open-appsec не является большой языковой моделью. Агент - это специализированный фоновый процесс, который анализирует входящие HTTP-запросы рядом с прокси.
Проверяются:
- URL и параметры запроса;
- заголовки;
- тело HTTP-запроса;
- структура обращения к приложению;
- признаки SQL-инъекций, XSS, RCE и других атак;
- соответствие трафика обычному поведению конкретного сервиса.
Условно в системе работают два подхода. Контролируемая модель сопоставляет признаки запроса с заранее известными шаблонами атак. Неконтролируемый компонент оценивает, насколько обращение отличается от нормального поведения приложения. Благодаря этому защита способна реагировать не только на точное совпадение с сигнатурой, но и на необычные комбинации признаков.
Разработчики также заявляют о способности агента обнаруживать некоторые атаки нулевого дня. Однако это не означает полной защиты от неизвестных уязвимостей: WAF не заменяет обновление компонентов, безопасную разработку и регулярное тестирование.
Ресурсы и производительность
Потребление зависит от количества сервисов, интенсивности трафика и сложности запросов. В небольшой лаборатории примерно на десять сервисов open-appsec может занимать около 1 ГБ оперативной памяти, а во время пиковых операций потребление способно подниматься примерно до 3 ГБ. На диске в конкретной конфигурации под компоненты и данные может потребоваться около 8 ГБ.
Согласно сведениям проекта, одно виртуальное ядро процессора способно обрабатывать ориентировочно до 500 запросов в секунду. Это усреднённая оценка, а не универсальная гарантия. На результат влияют размер тела запроса, количество правил, режим обучения и характеристики прокси.
При интенсивном сканировании, массовых запросах или DDoS-атаке нагрузка заметно увеличивается. На коротких пиках выделенные ядра могут быть загружены полностью. Поэтому перед публикацией сервиса стоит проверить производительность на собственном железе, особенно если через WAF проходят крупные файлы, изображения или большое количество API-вызовов.
Развёртывание локального стека
Для тестового запуска удобно использовать Docker Compose. В каталоге проекта создаются отдельные директории для конфигурации open-appsec, прокси и тестового приложения. Локальный файл политики, например `local_policy.yaml`, размещается в каталоге `appsec-localconfig`.
После запуска контейнеров необходимо проверить:
1. доступность прокси;
2. корректное прохождение обычного HTTP-трафика;
3. регистрацию агента;
4. наличие журналов событий;
5. работу режима обнаружения;
6. изменение поведения после перехода к блокировке.
На первом этапе лучше не включать жёсткую блокировку. Режим Detect-Learn позволяет собрать статистику о нормальном поведении сервисов и понять, какие запросы система считает подозрительными.
Проверка на SQL-инъекциях и XSS
Для практического тестирования удобно использовать Juice Shop или другое специально уязвимое приложение. В безопасной лаборатории можно отправить запросы с типичными признаками SQL-инъекций, XSS, попытками обхода фильтров и обращением к потенциально опасным путям.
В режиме обнаружения агент фиксирует событие, но не обязательно прерывает соединение. Это помогает убедиться, что правило срабатывает корректно и не мешает штатным операциям. После проверки можно перевести политику в режим блокировки и повторить тест.
Важно проводить такие эксперименты только на собственных системах или на стендах, где подобные действия разрешены. Даже безобидный на вид сканер способен создать значительную нагрузку или привести к блокировке приложения.
Что делать при ложных срабатываниях
Любой поведенческий WAF иногда может принять легитимный запрос за подозрительный. Такое случается с нестандартными API, сложными параметрами, загрузкой файлов, административными интерфейсами и интеграциями сторонних сервисов.
Если нужный запрос блокируется, сначала следует изучить журнал события и определить причину. Не стоит сразу отключать защиту целиком. Безопаснее:
- добавить узкое исключение для конкретного метода или маршрута;
- ограничить исключение определёнными параметрами;
- изменить режим проверки только для одного эндпоинта;
- дождаться накопления корректной статистики;
- отделить административные маршруты от публичных;
- повторно проверить исключение тестовым запросом.
Широкие разрешающие правила снижают ценность WAF, поэтому каждое исключение желательно документировать и периодически пересматривать.
Сильные и слабые стороны
Главным преимуществом open-appsec является сочетание локальной работы, относительно умеренных требований и автоматического анализа. В отличие от WAF, построенного исключительно на регулярных выражениях, агент учитывает контекст и поведение приложения.
К недостаткам можно отнести неидеальную документацию, необходимость разбираться в политике и логике обучения, а также зависимость результата от корректной интеграции с прокси. Не каждая архитектура подключается одинаково просто. Например, готовой универсальной связки с Traefik может не хватать, хотя энтузиасты находят обходные варианты через дополнительные компоненты вроде CrowdSec.
Также нельзя считать open-appsec заменой полноценной системе безопасности. Он не исправляет уязвимый код, не защищает от компрометации учетных записей сам по себе и не отменяет необходимость сетевой сегментации, резервного копирования и контроля доступа.
Практические рекомендации
Перед установкой в рабочую среду стоит заранее определить, какие сервисы должны проходить через WAF, какие запросы считаются нормальными и где будут храниться журналы. Для каждого приложения полезно иметь отдельную политику или хотя бы отдельные правила.
Рекомендуется начать с режима мониторинга, собрать статистику за несколько дней и только потом включать блокировку. При этом следует отдельно проверить авторизацию, загрузку файлов, веб-сокеты, API с JSON-телами и служебные health-check-запросы.
Полезно также ограничить доступ к панели управления, настроить ротацию логов и контролировать время хранения событий. При нехватке ресурсов лучше отключить ненужные тестовые сервисы, чем резко ослаблять защиту.
Итог
OpenAppSec - практичный вариант для тех, кому нужен локальный WAF с элементами машинного обучения без обязательной облачной зависимости. В небольшой homelab-среде он способен закрыть несколько веб-сервисов, обнаруживать распространённые атаки и постепенно адаптироваться к нормальному поведению приложений.
Его сильные стороны - умеренное потребление ресурсов, автоматический анализ и возможность работы в Docker-окружении. Слабые - необходимость аккуратно настраивать политики, контролировать ложные срабатывания и самостоятельно проверять совместимость с выбранным прокси.
Для небольшого продакшена и лаборатории open-appsec выглядит разумным компромиссом между простым набором сигнатур и тяжёлой коммерческой платформой. Но максимальный результат он даёт только в составе комплексной защиты: с обновлением приложений, безопасной конфигурацией, ограничением доступа и регулярными проверками.