Чек-лист по настройкам безопасности Check Point
Относительно недавно мы опубликовали в открытый доступ мини-курс «Check Point на максимум». Там мы попытались вкратце и с примерами рассмотреть самые частые ошибки в конфигурации Check Point с точки зрения ИБ. По сути мы рассказали чем плохи настройки по умолчанию и каким образом «закрутить гайки». Курс (неожиданно для нас) получил довольно хорошие отзывы. После чего, к нам поступило несколько запросов на краткую «выжимку» этого материала — чек-лист по настройкам безопасности. Мы решили, что это неплохая идея, в связи с чем и публикуем эту статью.
Перед началом мне хотелось бы сделать акцент на двух вещах:
- Данный чек-лист не является самодостаточным документом или руководством. Это лишь необходимый минимум проверок, которые желательно сделать. Дополнительные (расширенные) рекомендации можно получить только после детального обследования инфраструктуры.
- Чек-лист будет актуален не только для владельцев Check Point. Аналогичные проблемы с дефолтными настройками наблюдаются и у других вендоров: Fortigate, PaloAlto, Cisco FirePower, Kerio, Sophos и т.д.
А теперь сам чек-лист с небольшими комментариями по каждому пункту:
1)Включена HTTPS-инспекция
О важности HTTPS-инспекции я рассказывал во втором уроке «Check Point на максимум». Без этой опции ваш дорогой NGFW превращается в большую дыру в периметре сети.
2)Блокируются нежелательные ресурсы и приложения (App & URL filtering)
В Check Point за это отвечают два блейда — Application Control и URL Filtering. Практически тоже самое есть и у других вендоров с небольшими отличиями. Главная задача данных функций — уменьшить площадь атаки за счет блокировки доступа к потенциально опасным ресурсам или приложениям. Почему-то, несмотря на наличие преднастроенных категорий (Anonymizer, Botnets, Critical Risk, Hacking, High Risk, Phishing, Remote Administration, Sospicious Content, Spyware/Malicious Sites, Stealth Tactics и т.д.), люди не используют эти возможности ограничения. Лучше блокировать подобные вещи на сетевом уровне и не доводить до проверки трафика более тяжелыми средствами защиты (IPS, Antivirus, Anti-Bot, Threat Emulation). Это позволит избежать ложных срабатываний и сэкономит вам производительность шлюза. Изучите какие категории сайтов и приложений позволяет блокировать ваш шлюз, затем еще раз пересмотрите вашу политику доступа. Хорошим подспорьем здесь является SmartEvent, который может сгенерировать отчет по пользовательскому трафику.
3)Блокируется скачивание нежелательных файлов (Content Awareness)
Про это я рассказывал в третьем уроке. В Check Point за эту функцию отвечает блейд Content Awareness. У других вендоров возможно это позволяет делать либо Антивирус, либо DLP модуль. Смысл данного действия заключается в заведомой блокировке нежелательных типов файлов. Вашим пользователям точно нужно качать exe-файлы? А скрипты? Зачем проверять эти файлы и надеяться на надежность вашего шлюза, если можно блокировать их как нежелательный контент? Ниже нагрузка на NGFW и выше уровень защищённости. Иногда пользователь может даже не знать, что он начал что-то скачивать (фоновая загрузка). Пересмотрите свою политику, заблокируйте хотя бы исполняемые файлы.
4)Антивирус осуществляет полную проверку файлов (Antivirus — Deep scan)
Этим грешат абсолютно все вендора. В дефолтных настройках потоковый антивирус проверяет либо только хэш файла, либо несколько первых байтов. Для адекватной защиты этого недостаточно. Модифицировать вирус не составляет труда. Чтобы их ловить, нужна глубокая проверка. В Check Point-е за это отвечает опция deep inspection. Но будьте осторожны. Не стоит включать данную функцию абсолютно для всех файлов. Если у вас «слабый» шлюз, то нагрузка может возрасти слишком сильно. Используйте deep inspection для наиболее опасных (и часто скачиваемых) файлов: pdf, docx, xlsx, rtf, zip, rar, exe (если разрешаете их скачивать) и т.д. Более подробно смотрите в четвертом уроке.
5)Проверяются архивы, запароленные блокируются (Antivirus — archive scan)
Удивительно, но многие забывают про эту опцию. Думаю всем очевидна необходимость проверки архивов. И всем должно быть очевидно, что архивы с паролем нужно блокировать. Не вижу смысла расписывать здесь что-то подробнее. Просто проверьте, что у вас это настроено.
6)Включены дополнительные механизмы проверки (Antivirus — Protections)
В дефолтном профиле Threat Prevention (Optimized) выключены дополнительные механизмы проверки, такие как: Malicious Activity — Signatures, Unusual Activity — Behavioral Patterns. Не пренебрегайте этими настройками. Каким образом их включать я показывал в четвертом уроке.
7)IPS обновляется хотя бы раз в неделю
В пятом уроке я попытался показать, на сколько важен IPS для защиты сети. И одним из ключевых условий эффективности является «свежая» база сигнатур. Убедитесь, что ваш IPS обновляется достаточно часто. Моя рекомендация — хотя бы раз в три дня. Как правило, значения по умолчанию гораздо выше (от недели до месяца) практически у всех вендоров.
8)IPS вынесен в отдельный Layer
Еще один важный момент. Обязательно вынесите IPS в отдельный Layer. Только так вы сможете получить от него максимум. Я довольно подробно рассказал зачем и как это делать в шестом уроке курса.
9)Разные политики Threat Prevention для разных сегментов сети
В политики Threat Prevention входят такие блейды как: Antivirus, Anti-Bot, IPS, Threat Emulation, Threat Extraction. Как мы уже обусловились выше, IPS должен быть вынесен в отдельный Layer. Там у вас должно быть минимум две политики — одна для клиентский устройства, другая для серверных. При этом, в идеале политика должна дробиться еще сильнее, т.к. в каждом сегменте могут быть разные типы устройств и разные типы сервисов. Ключевая задача — включить только нужные механизмы защиты. Бессмысленно проверять windows-сигнатурами трафик, который предназначен Linux хосту. Тоже самое касается и других блейдов. Сегментированная политика Threat Prevention — залог адекватной защиты.
10)Используется Hold режим
По умолчанию для Threat Prevention используется режим background. Это значит, если файл новый и нет нужной сигнатуры, то он может пройти, пока в фоне идет «углубленная» проверка. Это не совсем то, что обычно требуется от средств защиты. Поэтому убедитесь, что в свойствах Threat Prevention (в глобальных настройках и настройках профиля) включен Hold режим.
11)Сформирована Geo Policy
Данную функцию также незаслуженно забывают. Эта опция позволит заблокировать для вашей сети любой трафик (как входящий, так и исходящий) любой страны. Вашим пользователям нужно посещать ресурсы Бангладеша или Конго? А ведь злоумышленники любят использовать сервера стран, где довольно слабо развито законодательство с точки зрения киберпреступности. Грамотная Geo-политика позволит не только повысить уровень безопасности, но и снизить нагрузку на шлюз, т.к. последнему не придется проверять все подряд.
12)Включен Threat Emulation
Здесь не обойтись одним пунктом. По хорошему нужно сделать отдельный чек-лист по настройкам Threat Emulation. С вашего позволения я не буду этого делать :) Остановлюсь на одной главной рекомендации — блейд должен быть включен. По каким-то причинам еще очень много администраторов считают эту функцию ненужной экзотикой. Включите хотя бы в режим Detect и посмотрите отчет через недельку. Вы будете удивлены. Если текущий уровень подписки не позволяет использовать этот блейд, то можно запросить демо-лицензию на 30 дней.
13)Отсутствуют False Positive
Последний в списке, но не по важности пункт. Я уже много раз повторял (и не устану повторять), что безопасность это непрерывный процесс, а не результат. Поэтому, даже если вы все хорошо настроили, вы должны как минимум проверять эффективность и результаты. Работает ли защита и нет ли ошибок? Самой просто пример это сделать — периодически проверять security-логи. Проверьте логи по Threat Prevention блейдам. Нет ли Detect-ов по событиям с Severity уровня High или Critical и Confidence Level со значением High. Пример фильтра по логам:
product_family:(Threat OR Endpoint OR Mobile) AND action: Detect AND severity:(Critical OR High) AND confidence_level:(Medium-High OR High)
Если вы увидели логи, которые подпадают под этот фильтр, то значит вы пропустили в сеть то, что должны были заблокировать. Либо вы что-то неправильно настроили, либо ваше средство защиты отрабатывает не так, как должно. Периодически проверяйте наличие подобных событий, либо настройте уведомления (функционал SmartEvent).
Best Practice
Большинство пунктов вы сможете найти в официальной документации Check Point. Мы уже публиковали целую подборку в статье «Инструкции и полезная документация Check Point». В нашем случае главным источником информации будет подборка статей — Best Practice и ATRG. Если вы являетесь счастливым обладателем продуктов Check Point, то данные топики обязательны к прочтению.
Заключение
На этом мы закончим нашу «чертову дюжину» проверок. Если вы приведете в порядок настройки своего шлюза в соответствии с этим списком, то уровень вашей защищенности будет выше, чем у 80% компаний (статистика из личного опыта). Повторюсь, что это лишь базовые проверки. Для расширенных и более конкретных рекомендаций нужен комплексный анализ текущих настроек и архитектуры сети. Здесь вы можете ознакомиться с примером отчета (Check Point Security Audit) по результатам подобного аудита настроек. При желании можно получить отчет с конкретными рекомендациями и инструкциями по исправлениям.
Дополнительные обучающие материалы можно найти в нашей группе или telegram-канале.
