СОИБ. Внедрение. Настройка Web Application Firewall, часть 1
Некоторые
тестеры-разоблачители WAF,
считают что достаточно поставить коробочку / подключить сервис и всё - можно
проводить свои изощренные эксперименты, выдавать разоблачительные статьи и разрабатывать на коленке собственные спасительные утилиты.
Моё мнение - WAF отлично справляется со своей задачей и нужно просто правильно его "готовить".
Посмотрим какие
настройки должны выполняться на WAF в реальных проектах (не считая инициализации, базовых и
сетевых настроек, подключения онлайн-сервисов)
и разберем подробно для чего эти настройки нужны:
·
Так как мы глубокий анализ трафика web трафика задача ресурсоемкая, а мы
хотим эффективно использовать ресурсы нашего WAF, то нам нужно точное определение области защиты (весь трафик
не касающийся области защиты будем пропускать без проверок):
o
определяем защищаемые площадки (Sites)
o
задаем перечень ip-адресов серверов web приложений (Server Groups)
o
для каждого сервера указываем сервисы и порты, связанные
с web приложениями
(web services)
o
определяем все web приложения,
расположенные на наших web сервисах (а их может быть больше 1, например: www.microtest.ru, www.security-microtest.ru) и задаем соответствие приложений
и URL. В дальнейшем это
нам поможет включать разные политики на разные приложения, а при мониторинге WAF и реагировании на инциденты поможет
быстро определить приложения, на которые производится атака. Это важно - за разные приложения могут отвечать разные группы разработчиков, специалистов
поддержки
·
Наиболее критические web приложения
будут использовать HTTPS для защиты передаваемой информации. Чтобы наш WAF хоть
что-то увидел нужно импортировать SSL сертификаты с закрытыми ключами для
каждого из web серверов (SSL inspection)
·
Задаем
шаблон сообщения об ошибке, для тех случаев когда запросы были
заблокированы WAF-ом.
Это позволит нам на этапе опытной эксплуатации определять и отделять ложные
срабатывания WAF от
ошибок web приложений.
<html><header><title>Error</title></header>
<body><H2>Внимание</H2><br>
Ваш запрос к web приложению не может быть
выполнен в связи с нарушением политик безопасности. Свяжитесь с службой
поддержки для получения дополнительной информации.<br>
Event id: $(EVENT_ID)<br>
</body></html>
·
Проблемой для нас будет, если используются
балансировщики трафика, а в крупных web приложениях они используются:
o
разместив WAF до балансировщиков, мы видим в поле ip-адреса назначения запросов
адреса балансировщиков, а не адреса защищаемых web серверов.
o
разместив WAF после балансировщиков мы видим в поле
ip-адреса источика
запросов – адреса балансировщиков, а не пользователей или атакующих.
o
можно подключить WAF до и после балансировщиков, но в
таком случае мы будем обрабатывать 2 раза один и тот же трафик и получать в 2
раза больше событий и нарушений
Одно из красивых решений:
разместить WAF после балансировщиков, а на балансировщиках настроить опцию
регистрации форвардинга, в которой в запрос будет добавляться указание ip-адреса источника (в опцию X-Forwarded-For). В таком случае, на WAF для
определенных web сервисов нам надо будет настроить распознавание ip-адреса источника из поля X-Forwarded-For.
Так-же мы не хотим чтобы ip-адреса балансировщиков
попадали в долговременный черный список (в отличае от ip-адресов атакующих) нужно добавить в
исключения в настройках реакций WAF
·
Полезным было бы задать в WAF структуру web приложений
с указанием всех каталогов, страниц и используемых параметров на каждой
странице. Это пригодится нам для тонкой настройки политик в дальнейшем
(например, мы захотим явно указать все страницы, на которых разрешено принимать
данные от пользователя или например, захотим отметить все страницы, на которых
могут отображаться персональные данные).
Вручную задавать такие данные – задача трудоемкая, а ведь надо ещё и
актуализировать при изменениях web приложений. Поэтому, хорошо если ваш WAF поддерживает
динамическое профилирование web-приложений.
В таком случае нам нужно его включить и настроить правила динамического
обновления профилей web приложений
На этом мы
закончим первую часть настроек, а впереди нас ещё ждет назначение политик
безопасности, определение ценных данных, маскировка информации, настройка
специализированных плагинов для конкретных web приложений, тюнинг профилей, жесткое
определение типов параметров и задание ограничений для них, настройка реакций, настройки
корреляции событий, настройка отчетов и окон мониторинга.
Жду отзывов –
интересны ли вам подобные статьи и стоит ли делать продолжение?
Комментарии
Задержка небольшая. Плюс мы её настраиваем детально, чтобы минимизировать нагрузку.
На случай если упадет - применяются пары bypass портов, которых как минимум 4 на борту.
Но статью я постарался сделать универсальной, такой чтобы подходила к любому WAF (это может быть fortinet, trustwave или даже опенсорсный ModSecurity для linux) - разница будет в деталях, удобстве и трудоемкости описанный действий