Как ELK помогает инженерам по ИБ бороться с атаками на сайты и спать спокойно

Наш центр киберзащиты отвечает за безопасность веб-инфраструктуры клиентов и отбивает атаки на клиентские сайты. Для защиты от атак мы используем файрволы веб-приложений FortiWeb (WAF). Но даже самый крутой WAF – не панацея и не защищает «из коробки» от целевых атак. 

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

Сегодня расскажу подробнее, как мы скрестили «ёлку» с WAF и что из этого получилось.

История одной атаки: как все работало до перехода на ELK

В нашем облаке у заказчика развернуто приложение, которое стоит за нашим WAF. В день к сайту подключались от 10 000 до 100 000 пользователей, количество подключений доходило до 20 млн. в день. Из них 3-5 пользователей были злоумышленниками и пытались взломать сайт. 

Обычный брутфорс формы с одного IP-адреса FortiWeb блокировал достаточно легко. Количество обращений к сайту в минуту было больше, чем у легитимных пользователей. Мы просто настраивали пороги активности с одного адреса и отражали атаку.

Куда сложнее бороться с  «медленными атаками», когда злоумышленники действуют не спеша и маскируются под обычных клиентов. Они используют много уникальных IP-адресов. Такая активность не выглядела для WAF как массовый брутфорс, отследить ее автоматически было сложнее. А еще был риск заблокировать нормальных пользователей. Мы искали другие признаки атаки и настраивали политику автоматической блокировки IP-адресов по этому признаку. Например, у многих нелегитимных сессий обнаруживались общие поля в заголовках http-запроса. Искать такие поля часто приходилось вручную в журналах событий FortiWeb. 

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

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

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

Выделенные поля помогают обнаружить «медленную атаку». Источник: скрин с сайта Fortinet. 

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

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

Из чего выбирали

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

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

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

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

Вот так мы и пришли к опенсорсу в лице ELK. 

Почему выбрали ELK 

ELK – это комплекс программ с открытым кодом:

• Elasticsearch – база данных временных рядов, которая как раз создавалась для работы с большими объемами текста;
• Logstash – механизм сбора данных, который может конвертировать журналы в нужный формат; 
• Kibana – хороший визуализатор, а также достаточно дружелюбный интерфейс для управления Elasticsearch. Можно с его помощью построить графики, за которыми могут наблюдать дежурные инженеры по ночам. 

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

Как собрали это все в единую систему

Сформировали индексы и оставили только нужную информацию. Мы загрузили все три журнала FortiWEB в ELK – на выходе получились индексы. Это файлы со всеми собранными журналами за период, например, сутки. Если бы мы сразу их визуализировали, то увидели бы только динамику атак. За подробностями нужно «проваливаться» в каждую атаку и смотреть конкретные поля.

Мы поняли, что для начала нужно настроить разбор неструктурированной информации. Взяли длинные поля в виде строк, например, «Message» и «URL», и распарсили их, чтобы получить больше информации для принятия решений. 

Например, с помощью парсинга мы вынесли отдельно местоположение пользователя. Это помогло сразу выделить  атаки из-за рубежа на сайты для российских пользователей. Блокируя все подключения из других стран, мы уменьшили количество атак в 2 раза и могли спокойно разбираться с атаками внутри России. 

После парсинга стали искать, какую информацию хранить и визуализировать. Оставлять в журнале все было нецелесообразно: размер одного индекса был большим – 7 Гб. ELK требовалось много времени для обработки файла. При этом не вся информация была полезной. Что-то дублировалось и занимало лишнее место – нужно было оптимизировать. 

Сначала мы просто просматривали индекс и удаляли ненужные события. Это оказалось еще неудобнее и дольше, чем работа с журналами на самом FortiWeb. Единственный плюс от «ёлки» на этом этапе – мы смогли визуализировать большой промежуток времени на одном экране. 

Мы не отчаивались, продолжали есть кактус изучать ELK и верили, что сумеем вытянуть необходимую информацию. После очистки индексов начали визуализировать что есть. Так мы пришли к большим дашбордам. Понатыкали виджетов – наглядно и нарядно, настоящая ЁLKа! 

Зафиксировали момент атаки. Теперь нужно было понять, как на графике выглядит начало атаки. Для ее обнаружения мы смотрели на ответы сервера пользователю (return codes). Нас интересовали ответы сервера с такими кодами (rc): 

Код (rc)

Название

Описание

0

DROP

Запрос к серверу блокируется

200

Ok

Запрос успешно обработан

400

Bad Request

Ошибочный запрос

403

Forbidden

Отказ авторизации

500

Internal Server Error

Сервис недоступен

Если кто-то начинал атаковать сайт, менялось соотношение кодов: 

• Если ошибочных запросов с кодом 400 становилось больше, а нормальных запросов с кодом 200 оставалось столько же, значит кто-то пытался взломать сайт. 
• Если при этом запросы с кодом 0 тоже росли, значит политики FortiWeb тоже «видели» атаку и применяли к ней блокировки. 
• Если увеличивалось количество сообщений с кодом 500, значит сайт недоступен для этих IP-адресов – тоже своего рода блокировка. 

К третьему месяцу мы настроили дашборд для отслеживания такой активности.

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

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

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

Тут все хорошо: был всплеск «красной» активности, но FortiWeb справился и график атаки сошел на нет.

Также мы нарисовали для себя пример графика, который требует вмешательства:

Здесь мы видим, что FortiWeb повысил активность, но красный график атаки не снизился. Нужно поменять настройки WAF.

Расследовать ночные инциденты тоже стало проще. На графике сразу видно момент, когда пора прийти на защиту сайта. 

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

Куда стремимся

Сейчас мы обучаем дежурных администраторов работать с ELK. Дежурные учатся оценивать ситуацию на дашборде и принимают решение: пора эскалировать на специалиста по FortiWeb, или политик на WAF хватит для автоматического отражения атаки. Так мы снижаем нагрузку на инженеров ИБ по ночам и делим роли в поддержке на уровне систем. Доступ к FortiWeb остается только у центра киберзащиты, и только они вносят изменения в настройки WAF при острой необходимости.

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

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

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

Источник: habr.com