Знакомимся с Check Point

Знакомимся с Check Point — как развернуть тестовую среду, где взять дистрибутив для образовательных целей, начальная настройка, использование SmartConsole.

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

Сегодня очередь немношк разобраться с Check Point Security Gateway (CP). Очень хороший бесплатный курс по Check Point. Рекомендую начать именно с него, с урока 2. Там прям клад ценной информации.

Но в этом курсе, на мой взгляд, есть сложности со стендом. Моя же статья поможет быстро развернуть стенд на EVE-NG и дальше уже свобода творчества для каждого.

Системные требования

Сразу скажу:

  • Если на компьютере 8Gb оперативной памяти, запустить такую лабу, к сожалению, не получиться. На образ CP выделяется 6Gb и они реально используются (при совмещённой установке Security Gateway с Security Management Server);
  • 8-16Gb могут быть какие-то некомфортные моменты, тормоза, глюки. Чем меньше памяти, тем тормозов и глюков будет больше;
  • 16Gb++ нормальный вариант.

После выполнения лабы, что описана тут, стал уже разносить Security Gateway и Security Management Server. На каждый образ по 6Gb. На Security Gateway использование примерно 60%, на Security Management Server 75. Потом я добавил кучу access-правил, повключал блейды, всё настроил и на Security Management Server пришлось увеличивать выделение памяти до 8Gb.

Потом добавил ещё несколько компов с Windows, коммутаторы CISCO, сервер с AD и лаба скушала около 30Gb. Прошу данные моменты учитывать, игрища в EVE-NG не для слабых машин.

Создание виртуальной среды

Образы Check Point поддерживаемые EVE-NG:

Checkpoint FW: R77-20, R77-30, R80-x

В качестве тестовой среды возьмём виртуальную машину EVE-NG от проекта PNETLab. Теперь образ Check Point. Берём тут. На выбор есть R77.30, R80.10 и R80.20.M1.

Релиз 77.30 хотя и сертифицированный, но староват. Возможно он заинтересует кого-то именно по причине своей сертифицированности. R80.20.M1 это Management Release и:

To be clear, this is for Management only (including
Provider-1/Multi-Domain) and does not support
installation as a gateway (with or without
management).

Поэтому остановился на релизе 80.10. Называется он cpsg-R80-10-T497.tar.gz, размер 3.9Gb. Кроме этого взял образ win-7-x86-IPCC.tar.gz для машин, подключенных к Check Point.

Образы закидываются в EVE-NG с помощью WinSCP, распаковка через SSH:

# cd /opt/unetlab/addons/qemu/
# tar xvzf cpsg-R80-10-T497.tar.gz
# tar xvzf win-7-x86-IPCC.tar.gz

cpsg-R80-10-T497/
cpsg-R80-10-T497/hda.qcow2

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

# cd /opt/unetlab/wrappers 
# ./unl_wrapper -a fixpermissions

После перезагрузки VM в списке нод появляется CheckPoint Security Gateway VE. По умолчанию на одну ноду нужно 4 ядра CPU, 6144Mb памяти, доступно 4 сетевых интерфейса. Всё довольно просто, но если возникли сложности, то велкам в статью Установка EVE-NG.

Пароли для доступа к устройствам в файлике EVE_image_login_credentials.csv, который нужно скачать вместе с образами. Для Win-машин user/Test123, CP admin/Test123 (для CP в файле ошибка).

На этом всё, можно вернуться к изучению курса. Я же продолжу рассказывать про свою лабу. Она ни в коем случае не имеет цели соперничать с курсом и возможно даже ошибочна в каких-то моментах. Но как примёр развёртывания в EVE-NG отлично подойдёт.


Место CP FW в корпоративной сети

Чтобы было понятно чего я там собрался настраивать, сначала обозначим где располагается CP в нашей сети. Это конечно же не единственный вариант, но рабочая схема, применяемая в продакшене.

Предположим что есть большая корпоративная сеть, подключенная к нескольким провайдерам (ISPs). Непосредственно к ISPs подключён граничный маршрутизатор/маршрутизаторы компании (CE, Customer Edge). Этот маршрутизатор анонсирует по BGP IPv4 PI-блок адресов (Provider Independent) в сторону роутера ISP (PE, Provider Edge).

На линке между CE и PE используются транспортные адреса, выданные провайдером. Обычно это публичные IPv4 адреса. То есть эти адреса не из нашего PI-блока. Просто какие-то адреса чтобы заработала связь между CE и PE. Таким образом, между нами и ISP одни адреса, а анонсируем мы ему совсем другие. Это важно.

CP FW стоит во внутренней сети сразу за CE. И фильтрует пакеты между внутренней сетью (LAN), группой серверов доступных с интернета (DMZ), внешней сетью (Internet). Кроме этого, при прохождении пакетов из LAN в сторону Internet нужно выполнить NAT (динамический NAT и/или NAT с перегрузкой) и заменить приватные адреса на адрес/адреса из нашего PI-блока. А для серверов из DMZ нужен статический NAT. Для всего этого на CE нужен маршрут для PI-блока в сторону CP.

Создание лабы

Лаба будет предельно упрощённая, чтобы проверить некоторые возможности только самого CP. Схема следующая:

Знакомимся с Check Point

Интерфейсы нужно соединить точно как на схеме. Тут Win1 это сервер из DMZ, а Win2 сразу и CE, и PE, и компьютер из интернета. Net тут только для закачки необходимых файлов на Win1.

Интерфейс e1 Win1 подключен к Net Manadgement(Cloud0) и получает настройки автоматически вместе с доступом к интернету от VMware Player.

Подсоединяемся к CP через консоль EVE-NG:

login: admin
Password: 
Last login: Sat Feb 20 02:32:00 on ttyS0
gw-000200> show interface eth0
state on
mac-addr 50:6f:e4:00:0b:00
type ethernet
link-state link up
mtu 1500
auto-negotiation on
speed 1000M
ipv6-autoconfig Not configured
duplex full
monitor-mode Not configured
link-speed Not configured
comments 
ipv4-address 192.168.1.1/24

Остальные интерфейсы не сконфигурированы.

Поэтому на интерфейсе e0 Win1 настраиваю 192.168.1.2/24, пока без шлюза. Шлюз на e1 для закачки файлов с нета.

Начальная настройка Check Point

Сначала нужно подцепиться с машины Win1 через браузер (https://192.168.1.1):

Знакомимся с Check Point

и выполнить первоначальную инициализацию:

Знакомимся с Check Point

Платформа определилась как Open Server. Инициализация обязательное действо, при этом можно:

  • Deployment Options, обновить версию из Check Point Cloud/с флешки или запустить Recovery — пропускаю, выбирая Setup (по умолчанию);
  • Management Connection и Internet Connection, настроить интерфейсы:
eth0 - 192.168.1.1/24, без шлюза - эмулирует подсеть DMZ 
eth1 - 1.1.1.1/30 - эмулирует транспортную подсеть между CE и PE
  • Device Information, Хостнейм, DNS, Proxy — по умолчанию;
  • Date and Time Settings, Время вручную или через NTP — по умолчанию;
  • Installation Type — по умолчанию (Security Gateway and/or Security Management);
  • Products — по умолчанию (Security Gateway + Security Management);
  • Security Management Administrator — по умолчанию;
  • Security Management GUI Clients, откуда можно подключаться к Security Management — по умолчанию.

Как видно, практически всё по умолчанию. Не стал заморачиваться и разносить Security Gateway (SG) с Security Management Server (SMS), для целей лабы непринципиально. Инициализация занимает некоторое время и завершается рестартом CP.

Знакомимся с Check Point

После инициализации захожу через браузер на CP ещё раз. Называется Gaia Portal и здесь можно выполнить различные настройки системы. Настраивать ничего не буду, перехожу сразу к скачиванию SmartConsole.

Запускаю SmartConsole, при первом подключении нужно установить Fingerprint:

Знакомимся с Check Point

Наконец попадаю в привычную и удобную среду:

Знакомимся с Check Point

На этом шаге для продакшена нужно зайти в свойства шлюза (двойной щелчок), Network Management и для каждого интерфейса настроить пункт Topology. Как это сделать хорошо и подробно рассказывается в курсе, о котором говорил в начале.

Но для моего примера данный момент не имеет значения и Anti-Spoofing мне здесь не нужен. Поэтому данные действия пропускаю.

Настройка лабы

Настраиваю на e0 Win1 шлюз 192.168.1.1, на Win2 1.1.1.2/30 шлюз 1.1.1.1. Сначала на CP есть единственное правило, которое запрещает любой трафик:

Пингую с Win1 1.1.1.2, пингуется, и 1.1.1.3, и 1.1.1.4.. Забыл выключить интерфейс e1, через него пакеты уходят в реальный интернет, а там такие адреса есть. 🙂 Всё, интерфейс выключен, ничего и ниоткуда не пингуется, как и должно быть.

Настраиваем чтобы пакеты от Win1 проходили через FW. Поскольку FW у нас stateful, обратный трафик автоматически разрешён и значит нужно только 1 правило:

Но пока созданное правило не работает. Нужно выполнить Publish (установка на SMS, желтым горит количество изменений), затем Install Policy (установка на SG, тоже будет показано количество изменений). Вот такой механизм в CP. Если SMS обслуживает несколько нод SG, то надо указать на какую ноду накатываем политику.

Проверяем, c Win1 всё пингуется. Дальше добавляем правило, чтобы с Win2 можно было пинговать интерфейс eth1 CP:

Проверяем, с Win2 интерфейс CP 1.1.1.1 запинговался.

Теперь допустим, мы анонсируем ISP PI-блок 187.187.197.0/24 (адресация взята с потолка). Тут важный момент, что блок менее чем /24 ISP не примет. Поэтому нельзя анонсировать ISP, скажем, хост (/32). Фильтры такой анонс откинут.

Нам надо чтобы наш сервер DMZ единообразно транслировался в 187.187.197.240. Добавляем 2 правила NAT:

В первом правиле у нас пакеты с сурсом 192.168.1.2 преобразуются в пакеты с сурсом 187.187.197.240. Во втором пакеты, предназначенные 187.187.197.240 перенаправляются на 192.168.1.2. Буква s рядом c хостнейм означает статический NAT (static).

Ну и предположим что с внешнего ресурса Win2 мы хотим попадать на 192.168.1.2 через RDP. Плохой пример, в продакшене порты будут 80, 443 либо какие-то специфические. Почему взял RDP? Это протокол, работу которого легко проверить именно в этой лабе. Значит нужно разрешить запросы извне на 187.187.197.240, указав порты:

Теперь проверяем с Win2:

Вводим реквизиты, на Win2 RDP сессия к Win1 установилась, а на EVE-NG отключилась. Под одним пользователем доступна только одна сессия по умолчанию.

Несколько замечаний по добавлению правил:

  • Лучше сразу составить регламент по единообразному именованию хостов и сетей. Особенно хорошо поможет, если CP настраивается несколькими инженерами;
  • Желательно заполнять поле комментария (по умолчание это поле не выводится, его нужно включить в просмотре). Как вариант туда можно поместить номер заявки из сервис-деска, по которой это правило добавляется, дату, фамилию инженера. И хотя есть Audit Log, там можно посмотреть кто/что делал, но комментарий очень удобная штука. Бережёт время;
  • Логирование надо включать на всех правилах, за исключением супернагруженных. Иначе потом буду сложности с поиском нужного трафика в логе.

Просмотр лога

Последнее что тут хотел отметить, очень удобный просмотр лога:

Присутствует достаточное количество фильтров. Можно кликнуть два раза на строчку лога и откроется дополнительная информация. Это всё что хотел рассказать сегодня. Ссылка на гайды, пароль: 127345.

Добавить комментарий