Работая с шлюзами безопасности компании Check Point, очень часто возникает задача разбора логов для обнаружения и анализа инцидентов информационной безопасности. Обычно в организациях существует уже какая-либо система логирования, и стоит задача транспортировки логов с сервера управления Check Point и последующая настройка фильтров для логов, составление дашбордов, графиков и так далее. В данном курсе мы рассмотрим различные варианты анализа логов Check Point с помощью внутреннего функционала и сторонних приложений, рассмотрим какую полезную информацию мы можем извлечь, и чем она поможет в настройке межсетевого экрана.
В рамках продуктов компании Check Point за это отвечает функционал SmartEvent, который будет строить отчеты по шаблонам, также можно настроить ограниченный набор автоматических действий, но сейчас не об этом, к этому вопросу мы вернемся позднее. Также существуют другие решения по данной задаче, которые были рассмотрены в наших других статьях:
- Splunk + Check Point, пример анализа логов вашего фаервола
- Check Point Smart Event. Мини-руководство
Настройка всех вышеперечисленных решений требует определенной квалификации и большого количества времени на внедрение. Что если требуется получить решение здесь и сейчас? Недавно компания Check Point выпустила приложение, которое идеально подходит для этого случая — Check Point App for Splunk, данные для которого пересылаются по syslog с помощью инструмента log exporter в режиме реального времени на систему логирования Splunk. В этой статье мы детально рассмотрим данное решение, установку, и информацию, которую получаем на выходе.
Требования при установке
Со стороны сервера управления Check Point требуется установленный инструмент Log Exporter, для того чтобы отправить логи по протоколу syslog. В версии GAIA R80.20 Log Exporter установлен по умолчанию, но для поддержки формата логов Splunk требуется установить Jumbo Hotfix, в остальных версиях перед установкой Log Exporter сначала необходимо установить для поддержки Jumbo Hotfix.
Все требования по версии хотфикса указаны далее:
- R80.20 — Jumbo Hotfix Take 5 or higher;
- R80.10 — Jumbo Hotfix Take 56 or higher;
- R77.30 — Jumbo Hotfix Take 292 or higher.
Для работы приложения минимальная версия системы должна быть не ниже Splunk 6.5, также должен быть установлен пакет Splunk Common Information Model (CIM).
Установка и запуск
Процесс установки довольно тривиальный, сначала устанавливаем Log Exporter, затем приложение на Splunk, настраиваем процесс отправки логов на сервере управления и процесс принятия в системе логирования, и конечным пунктом запускаем транспортировку логов, проверяем что все работает, как и ожидалось. Рассмотрим все пункты чуть поподробнее.
1.Установка Jumbo Hotfix согласно требованиям.
Заходим в GAIA портал в веб браузере, в левом меню Upgrades (CPUSE), Status and Actions, выбираем рекомендованный пакет Jumbo Hotfix, который явно по версии будет выше чем нижний порог в требованиях, либо ищем нужную версию в Add Hotfixes from the Cloud, устанавливаем, процесс потребует перезагрузку сервера управления.
2. Устанавливаем Log Exporter, если ваша версия Check Point ниже R80.20.
Для того чтобы установить на менеджмент Log Exporter, сначала скачиваем архив с портала Check Point.
Затем опять заходим в меню CPUSE-> Status and actions, выбираем Import Package, указываем путь к архиву, импортируем. После этого меняем просмотр пакетов c Showing Recommended packages на Showing All packages, выбираем импортированный архив, устанавливаем.
3.Устанавливаем CIM если не устанавливали до этого.
Заходим на Splunk WebUI, находим пакет CIM в Manage Apps -> Browse More Apps, устанавливаем.
4.Устанавливаем Check Point App for Splunk
Скачиваем архив с портала, далее заходим в Splunk WebUI, Manage Apps, Install app from file, выбираем нужный архив, нажимаем upload. ждем уведомления об успешном выполнении операции, убеждаемся, что приложение теперь видно в списке Apps.
Так должно выглядеть установленное приложение, разумеется среди других приложений:
Для того чтобы отправить логи по syslog, сначала необходимо создать процесс Log Exporter, затем настроить загрузку данных ( Data Input ) на Splunk, и запустить созданный процесс на сервере управления Check Point.
5. Конфигурируем Log Exporter
На сервере управления Check Point в CLI, в expert моде запускаем команду:
cp_log_export add name [domain-server <domain-server>] target-server <target-server> target-port <target-port> protocol <tcp | udp> format splunk read-mode <raw | semi-unified>
где — имя конфигурации, <target-server> — ip address системы Splunk на который пересылаем данные, <target-port> — порт на который отправляем данные.
Пример: cp_log_export add name check_point_syslog target-server 10.10.1.159 target-port 9000 protocol tcp format splunk read-mode semi-unified
6. Настраиваем Data Input на Splunk
Заходим на Splunk WebUI, в меню выбираем Settings, под разделом Data выбираем Data inputs.
Выбираем протокол по которому будут идти данные на Splunk, в данном примере tcp, выбираем +Add new.
Далее вводим порт <target-port>, который указывали в Log Exporter, в данном случае 9000, дополнительно можно указать с какого ip адреса принимать соединения, далее ждем кнопку Next.
В source type указываем cp_log, method – IP, index можно оставить default, все данные будут идти в index = Main и если у вас есть другие данные по этому индексу, время поиска может заметно увеличиться, можно указать другой индекс или создать новый, и тогда в самом приложении надо напрямую указать в каком индексе осуществлять поисковые операции.
После нажимаем Review, смотрим что все настройки соответствуют действительности, выбираем Submit, настройка Data Inputs закончена, остается только отправить логи с сервера управления Check Point.
7. Стартуем процесс загрузки логов на Splunk
В expert моде вводим команду:
cp_log_export restart name , где — это название конфигурации, созданное на первом шаге
Пример: cp_log_export restart check_point_syslog
Настройка закончена, после этого остается лишь убедится в том, что логи пошли на Splunk, использую стандартные механизмы поискового запроса на Splunk.
Теперь можно переходить к аналитике работы самого приложения, какие дашборды и отчеты оно содержит, какую важную информацию можно получить и какие выводы можно сделать.
Анализ логов
Приложение поделено на 2 секции – General Overview и Threat Prevention Protection, который в свою очередь делится на Cyber Attack Overview, Sandblast Protection и Additional Threat Prevention Events. Рассмотрим отдельно каждую секцию.
General Overview
Главная страница приложения представляет несколько таблиц, статистик и графиков. Некоторая информация в данном случае базовая, например, как количество шлюзов и серверов управления, или количество логов по блэйдам, скорее всего ничего нового вы тут не узнаете, и на основе данной информация нельзя сделать выводы, которые дадут положительный эффект.
С моей точки зрения, наиболее интересными элементами здесь являются Critical Attack Types, Critical Attacks Allowed by Policy, Infected Hosts, Allowed High Risk Applications, объясню почему.
По информации с Critical Attack Types, Critical Attacks Allowed by Policy можно улучшить политику безопасности Threat Prevention (переводя действия из detect в prevent по конкретным сигнатурам или повысив уровень срабатывания), тем самым повысив уровень безопасности по защите от вирусных угроз, попыток внедрения и взлома вашей инфраструктуры. Infected Hosts указывает на тех пользователей, которые возможно заражены, и соответственно в дальнейшем следует их отдельно проверить антивирусом или изолировать из сети, воспрепятствовав прохождения вируса по сети организации. Исходя из диаграммы Allowed High Risk Applications можно заблокировать для пользователей наиболее посещаемые потенциально опасные приложения, которые в данный момент разрешены.
Диаграммы Applications and URL Filtering by Risk, Security Incidents by Severity и Attack Actions by Policy носят систематический характер и говорят о том, улучшается ли состояние ИБ в вашей организации с течением времени, то есть помогли ли больше обезопасить инфраструктуру внесенные изменения в политику безопасности.
Cyber Attack Overview
На этом дашборде показана более детализированная информация по зараженным хостам и по пользователям, которые скачивают вирусы. Очень удобно разделение по скаченным зараженным файлам и по зараженным письмам, можно определить угрозы и составить политику безопасности Threat Prevention по отдельным сервисам, один профиль безопасности под smtp трафик и другой профиль под http и https. В SandBlast Protection указана более детализированная информация по зараженным файлам, вы можете посмотреть на Severity и определить недостатки вашего профиля безопасности в Threat Prevention.
Заключение
Благодаря данному приложению, очень быстро и удобно можно получить информацию по слабым местам в вашей политике безопасности, настройка приложения занимает немного времени, и не требует большой квалификации по данным решениям. То есть если вы сомневаетесь в своих настройках системы безопасности и вам требуется некий анализ без больших затрат времени, то это очень удобное решение. Однако видно, что приложение еще серьезно нуждается в доработке, нет статистики по пользователям, очень интересно увидеть список наиболее используемых приложений и объем трафика, который там ходит и т.д. Так как это только первая версия, приложение будет обновляться, и скорее всего со временем это будет очень хорошее решение по анализу, но сейчас если рассматривать данное приложение только как анализ логов, то оно сильно уступает другим решениям. В последующих статьях мы рассмотрим и сравним возможности SmartEvent и других приложений Splunk по анализу логов Check Point, в том числе и приложения, созданного нашими инженерами.
Если вы все еще не пробовали Splunk для анализа логов Check Point, то самое время начать. Если у вас есть вопросы или проблемы со Splunk или Check Point — вы можете задать их нам, а мы поможем.
Автор: GlebRyaskin
