Splunk + Check Point, пример анализа логов вашего фаервола

Если Вы не удовлетворены стандартными отчетами и средствами аналитики от Check Point, если Ваш Smart Event виснет и грузит ваш сервер, если отчеты Smart Event кажутся Вам несколько неинформативными… То почему бы не создать свои?



Сегодня мы расскажем как загрузить логи Check Point в Splunk, какие могут быть отчеты, и как, отфильтровать данные, чтобы лишний раз не грузить систему и уменьшить лицензию. И да, если Ваша компания не очень большая — то вы можете спокойно обойтись бесплатной лицензией.

Загрузка логов в Splunk

1. Нам потребуется сервер со Splunk, установленный поверх Linux (из-за специфики OPSEC протокола), мы обычно используем CentOS. О том как установить Splunk мы писали раньше здесь.
   
   
2. На Splunk нужно установить Add-on for Check Point OPSEC LEA, пошаговая инструкция здесь. Для загрузки аддона со SplunkBase можно воспользоваться той же учетной записью, которую Вы создали, чтобы скачать Splunk.
   
   
3. Далее нужно:
   
   
   Подготовить сам Check Point Management Server:

   В Smart Dashboard: File → Manage → Servers And OPSEC Applications → New → OPSEC Application
   
   
   
   Даем ему любое имя (оно нам понадобиться дальше), в поле host выбираем сервер со Splunk если он уже забит в Check Point или создаем новый host c адресом Splunk сервера. Заходим на вкладку Permissions и смотрим чтобы стояла шалока на Show all log fields. Возвращаемся на предыдущую вкладку, отмечаем галочку LEA и нажимаем кнопку Communication.
   
   
   
   Там вводим любой одноразовый пароль (запоминаем его)
   
   
   
   После чего устанавливаем базы данных File → Policy → Install Database:
   
   
   
   После чего нужно создать правило которое открывает 18210 и 18184 порты для сервера со Splunk и проинсталировать политики.
   
   
4. Установить следующие пакеты на Linux сервер:
   
   

   yum install glibc.i686
   yum install pam.i686

   
   
5. Далее нужно:
   
   
   Cконфигурировать Аддон на самом Splunk

   После установки OPSEC аддона у вас должна появится его иконка
   
   
   
   Заходим в него → Configuration → Add Connection и вводим свои данные (важно: название приложения должно совпадать с тем, что вы указали на Check Point сервере, ну и одноразовый пароль тоже)
   
   
   
   Далее переходим во вкладку Inputs выбираем какие логи загружать (для полноты выбираем No Audit)
   
   
   

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

index=* sourcetype=opsec*

Фильтрация

Если у вас выключена https инспекция и нет песочницы, то 90% логов — будут логи отработки фаервольных правил, они на самом деле мало интересны. В большей степени представляет интрес логи таких блейдов как Application Control, URL Filter, Anti-Virus, Anti-Bot ну и IPS конечно же.

Для того чтобы Splunk не индексировал логи отработки фаервольных правил надо создать два текстовых файла props.conf и transforms.conf и положить их в папку:

opt/splunk/etc/apps/Splunk_TA_checkpoint-opseclea/local

Содержимое props.conf:

[opsec]
TRANSFORMS-security= events-filter

Содержимое transforms.conf:

[events-filter]
REGEX=(.+product\=VPN\-1\s\&\sFireWall\-1)
DEST_KEY=queue
FORMAT=nullQueue

Мы не будем подробно описывать логику этих файлов, так как это достаточно длительный процесс. Подробное описание каждого из них есть на сайте с документацией (props.conf / transforms.conf).

Важно! Чтобы изменения вступили в силу, нужно перезагрузить сервер со Splunk.

Визуализация логов

Мы показали один из вариантов представления логов Application Controll и URL Filter выше. Ниже представлены его составные части вместе с запросами.

Количество событий срабатывания блейдов во времени

index=* sourcetype=opsec*  product="Application Control" OR product="URL Filtering" action!=redirect app_risk>2 NOT bytes=* app_risk>2
| dedup _time, user, s_port, src, dst
| timechart count as "Count of Events" | predict "Count of Events"

Топ 5 пользователей

index=* sourcetype=opsec*  product="Application Control" OR product="URL Filtering" action!=redirect  NOT bytes=* app_risk>2
| dedup _time, user, s_port 
| stats count  by user | sort -count | head 5

Количество событий в день с учетом тренда

index=* sourcetype=opsec*  product="Application Control" OR product="URL Filtering" action!=redirect  NOT bytes=* app_risk>2
| dedup _time, user, s_port 
| timechart count span=1d

Топ 5 приложений/сайтов

index=* sourcetype=opsec*  product="Application Control" OR product="URL Filtering" action!=redirect NOT bytes=* app_risk>2
| dedup _time, user, s_port 
| stats count  by appi_name | sort -count | head 5

Сводная таблица

index=* sourcetype=opsec*  product="Application Control" OR product="URL Filtering" action!=redirect app_risk>2 NOT bytes=*
| dedup _time, user, s_port 
| stats  values(matched_category) as Category,dc(user) as Users, values(app_risk) as Risk, values(action) as Action, dc(loc) as test by appi_name 
| sort -test 
| join type=left appi_name
[search index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering"   action!=redirect app_risk>2  bytes=* 
| dedup _time, bytes, received_bytes, sent_bytes 
| eval mb=received_bytes/1024/1024+sent_bytes/1024/1024
| stats sum(mb) as Traffic by appi_name]
| rename appi_name as "Application/Site", test as Count
| table "Application/Site", Category, Users, Action, Risk, Traffic, Count

Выводы

В этом примере мы показали как можно использовать Splunk для анализа логов Check Point. Это небольшой пример, касающийся лишь двух программных блейдов, но из него хорошо видны возможности системы. Мы также не касались темы алертов или запуска скриптов по результатам запросов, но это все естественно возможно.

И да, помимо логов Check Point в этот же Splunk можно загрузить логи другой системы, например RSA Аутентификации и анализировать уже их взаимосвязи, но это плавный переход в тему SIEM и отдельный разговор.