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

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

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

Сегодня очередь немношк разобраться с Check Point Security Gateway (CP). В нете полно статей, все они мало помогут без возможности пощупать технологию руками. Эта же статья поможет быстро развернуть стенд и дальше уже свобода творчества для каждого. Каких-то супер примеров не будет, но если раньше не работал с CP, думаю хорошо поможет.

Место 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.

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

Образы 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. Кроме этого взял образ 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

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

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

Установка довольно проста, но если возникли сложности, то велкам в статью Установка EVE-NG.

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

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

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

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

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

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

Подсоединяемся к 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, пока без шлюза.

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

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

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

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

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

Это обязательное действо, при этом можно:

  • Обновить версию из Check Point Cloud/с флешки или запустить Recovery — пропускаю;
  • Настроить интерфейсы;
eth0 - 192.168.1.1/24, без шлюза - эмулирует подсеть DMZ 
eth1 - 1.1.1.1/30 - эмулирует транспортную подсеть между CE и PE
  • Хостнейм, DNS, Proxy — пропускаю;
  • Время вручную или через NTP — пропускаю;
  • Выполняемую роль: Security Gateway/Security Management/Multi-Domain Server — Security Gateway + Security Management;
  • Кластер — пропускаю;
  • Дополнительного админа — пропускаю;
  • Откуда можно подключаться к Security Management — пропускаю

Инициализация занимает некоторое время и завершается рестартом CP.

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

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

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

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

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

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

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

Настраиваю на 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 (желтым горит количество изменений), затем Install Policy (тоже будет показано количество изменений). Вот такой механизм в CP. Если несколько нод, то надо указать на какую ноду накатываем политику.

Проверяем, 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 отключилась. Под одним пользователем доступна только одна сессия по умолчанию.

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

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

Это всё что хотел рассказать сегодня.

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