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



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

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

Во-вторых, с WAF на передний план выходит проактивная эксплуатация – реагирование на инциденты в режиме, близком к онлайн, анализ и оперативный тюнинг политик и профилей. Это особенно актуально в случае гибридного режима работы, когда часть сработок не блокируется, а лишь фиксируется WAF`ом. Делается это для минимизации рисков блокировки легитимных запросов.

В-третьих, в силу сокращения релизного цикла проблема динамического контента и профилирования требует наличия специалистов по эксплуатации, работающих в режиме full-time.

Эксплуатация WAF

Что же входит в задачи эксплуатации? Я выделил четыре основных направления:

1. Обновление – отслеживание патчей, в том числе закрывающих ошибки. Об этом было сказано выше, поэтому двигаемся дальше.
2. Написание частных сигнатур:
   
   • Отслеживание новых критичных сигнатур, совместные с заказчиком тестирование и подготовка контрмер на период, пока не выпущены официальные обновления (если нет возможности написать кастомные).
   • написание сигнатур в качестве компенсационных мер по закрытию уязвимостей исходного кода приложений:
     
     • уязвимости, известные разработчикам, закрытие которых требует масштабных доработок исходного кода;
     • уязвимости, выявленные в результате анализа исходного кода приложений.
3. Профилирование запросов, обращений к страницам сайта, приложению.
4. Validation – проверка и анализ параметров запросов/ответов на защищаемый ресурс/приложение.

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

Думаю, не вызывает сомнений то, что вариант «пришел-настроил-включил-работает» в 99% случаев не жизнеспособен и не работает на динамически изменяющемся контенте. Исключения составляют те заказчики, которые включают блокировку запросов по статическим сигнатурам, исключают тестирование обновлений, прилетающих на WAF и сразу «накатывают» их в продакшн. То есть если мы не говорим об обучающем функционале WAF, цикле обновлений, установки патчей по RFC, создания политики под конкретный защищаемый ресурс – возможно вам и не требуется специалист на full time или сервис по эксплуатации.

Режим работы WAF

Первый вариант: только блокирование – по сигнатурам и профилю. Здесь надо учитывать два момента: 1) есть достаточно высокий риск заблокировать легитимные запросы; 2) и, наоборот, WAF может пропустить запросы, эксплуатирующие уязвимости и дыры. Может случиться так, что при масштабном сканировании 99,9% запросов будет заблокировано, а 0,1% пройдет, но и этого будет достаточно для успешной атаки. По факту анализа 0,1 % пишутся и добавляются в блок новые кастомные сигнатуры.

Второй вариант: только уведомление. В этом случае по факту срабатывания сигнатур необходимо проводить комплексное расследование и коррелировать данные с другими источниками, например, с базами данных в случае использования SQL-инъекций. Учитывая огромный объем срабатываний WAF, проанализировать их все вручную практически невозможно.

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

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

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

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

Ниже пример настройки групп сигнатур одного из наших клиентов. В рамках оказания сервиса мы подключили WAF и логи веб-сервера (IIS) к SIEM-системе Solar JSOC. Критичные сигнатуры ставятся в блокирующий режим, логируются и добавляются в список обучения, на тот случай, если необходимо будет внести исключения:



Настройки параметров контента:



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



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

Кастомные сигнатуры

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

В случае появления серьезной уязвимости, какой, например, была shellshock, требуется оперативная доработка политики. Обычно служба эксплуатации WAF может реализовать ее в течение 1-2 часов, в то время как вендору может потребоваться до нескольких суток. Промедление в таких ситуациях грозит успешной эксплуатацией уязвимости, так как злоумышленники работают практически мгновенно, запуская сканирование всех белых адресов в интернете на подверженность уязвимости.

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

Работа с динамическим контентом

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

1. Сформированная политика выгружается с боевого сервера в тестовую среду.
2. В процессе тестирования обновленного контента одновременно тестируется совместимость с текущей политикой WAF, в случае необходимости производится ее корректировка.
3. В идеальной схеме обновление приложения или сервиса тестируется на пилотной группе (регионе). На этом этапе политика WAF переводится в блокирующий режим и тестируется в боевых условиях. Так же осуществляется тюнинг и тонкая настройка конфигурации политики.
4. Далее обновление и политика применяется глобально ко всем клиентам заказчика и становится эталонной до следующего обновления.

В идеальном мире есть предпродуктивные среды, функциональные и нагрузочные тесты длительностью примерно в 2 недели. Но жизнь иногда расставляет все по-другому. Примерно в 30% случаев нам приходится работать с сокращенным режимом разработки приложений и веб-сайтов у заказчиков, когда обновление сразу «накатывается» на продуктивные серверы. В этом случае необходимо оперативно подстроить политику WAF под новые условия работы. Для этого профилирование запускается на короткий промежуток времени – полдня-день. Из-за большого объема трафика этого зачастую достаточно для обучения. Спустя это время «допрофилированная» обновленная политика переводится в блокирующий режим.

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

Вот два ярких примера цикла разработки у наших клиентов:

Первый случай – заказчик выпускает один релиз в неделю. При этом взаимодействие между заказчиком и подрядчиком не предусматривает детального release notes, по которому можно понять, нужна ли корректировка политики. Единственный вариант – работа «на горячую» с коротким и оперативным циклом тюнинга политики WAF:



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

Интеграция WAF с SIEM: как правильно и что нужно?

Если компания использует собственный или аутсорсинговый Security Operations Center, подключение WAF к SIEM-системе позволит наладить оперативное уведомление и разбор по всем типам инцидентов, в том числе и веб-атакам, из одной точки – SIEM-системы.

Для фиксации и дальнейшего расследования инцидентов в SIEM-системе необходимо подключение следующих источников:

• Непосредственно сам WAF.
• Логи веб-сервера. Как и говорилось выше, включение логирования всех запросов на WAF может вызвать чрезмерную нагрузку, поэтому проще подключить журналирование на IIS или Apache.
• Логи приложения, защищаемого WAF, для отслеживания запросов.
• Логи БД для отслеживания запросов.

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

При подключении WAF необходимо понимать, какие поля, заголовки и метаданные пригодятся в расследовании инцидентов. В качестве примера рассмотрим подключение F5 ASM к ArcSight.



Из необходимых полей стоит выделить:

Дата и время фиксации события
Имя сигнатуры – для примера, «Illegal request length»
Тип атаки – для примера, «Session Hijacking»
Запрашиваемый URL:

/login?_*********=/sitebuilder/****/myaccount/login/*******form

Метод запроса – GET, POST, etc.
Адрес, с которого пришел запрос
Адрес, на который пришел запрос
Протокол соединения
Код ответа сайта
Имя политики, по которой сработала сигнатура
Дата и время применения этой политики

Несмотря на ограничение в 1024 символа в customstring-полях ArcSight, мы «замапили» туда весь запрос, анализ которого очень часто пригождается в расследовании:



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

1. Аномальное количество различных сработавщих на WAF сигнатур с внешнего хоста – потенциальное сканирование на уязвимости.
2. Срабатывание сигнатур в течение нескольких дней подряд с одного внешнего хоста – медленное сканирование.
3. Срабатывание порогового значения сигнатур за короткий промежуток времени с разных хостов – распределенное сканирование/DDoS уровня приложения.
4. Попытка эксплуатации критичной уязвимости. В случае сработки этого сценария, наши специалисты, совместно с заказчиками, анализируют не только логи WAF, но и успешные запросы с того же адреса на веб-сайт. Далее, по результатам анализа и при возникшей необходимости, происходит доработка политики WAF.

После того как специалисты первой линии оповестят службу эксплуатации WAF, последние имеют возможность подключиться уже к интерфейсу СЗИ и в режиме реального времени «тюнить» политики для противодействия атаке. Подключение к SIEM-системе позволяет не только наладить оперативное оповещение о потенциальных инцидентах, но и обогащать информацию об атаках сведениями из других систем, а также производить сложную корреляцию по цепочкам событий. Например, для понимания успешности атаки информацию с Web Application Firewall можно коррелировать с запросами в SQL-базах данных или локальными логами веб-сервера.

Наш подход к обработке инцидентов:



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

Заказчику необходимо контролировать подозрительные операции – слишком большое количество списанных бонусов или транзакций с бонусами за определенное время. В качестве инструмента для сбора сводной статистики используется отдельная таблица (Active List в ArcSight). Ежедневная выгрузка из этого листа отправляется аналитику для изучения аномалий, не попадающих в текущие корреляционные срабатывания.

В одной из таких выгрузок была обнаружена запись:

modify_order_bonus  ":"{\"bonusAvailable\":18.0,\"bonus\":-20000}" reason: success

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

Но и это еще не все: при дальнейшей обработке заказа в специализированных системах, куда передавалась информация с веб-сайта, значение требуемых к списанию бонусов бралось по модулю! Так клиент успешно получил скидку в 20 тысяч рублей при наличии на счету 18 баллов.

Web Application Firewall не увидел ничего аномального, так как структура запроса была правильной, и количество запросов не было подозрительным. Лишь последующий сбор статистики и просмотр событий глазами живого аналитика позволил выявить успешную попытку мошенничества в ключевом бизнес-приложении клиента.

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

Защита окружения приложений

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

Решить эту задачу силами WAF невозможно, это работа для SIEM-системы. Кейс по защите ключевого приложения решается комплексно и обычно к подключаемым в SIEM источникам относятся:

• Логи операционных систем серверов приложений, баз данных, вспомогательных систем, терминальных серверов.
• Логи межсетевых экранов, отделяющих сегмент приложения от остальных.
• Логи WAF.
• Логи приложения (front-end, back-end).
• Логи веб-серверов.
• Логи базы данных приложения, хотя бы на уровне аутентификации, а лучше – на уровне запросов в саму базу.
• Логи VPN в случае работы подрядчиков с приложением через удаленные соединения.

Далее происходит анализ текущих рисков и векторов потенциальных атак, мошеннических операций и нарушений в работе приложения:

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

На основе определенных выше векторов определяются необходимые к подключению источники и точки контроля в виде корреляционных правил, настраиваемых в SIEM-системе.

Состав правил выявления инцидентов обычно включает три блока:

• Контроль действий пользователей – обращения к приложению/базе данных, работе в нем всех типов пользователей, в том числе привилегированных.
• Контроль целостности ключевых таблиц, файлов, веток реестра, настроек окружения, запущенных служб и процессов.
• Выявление аномалий – сбор профилей на основе статистики и дальнейший мониторинг отклонений от него.

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

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

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

https://habrahabr.ru/post/332846/