Знакомимся с 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. Берём тут (EVE-FULL). На выбор есть 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 или даже без NAT.
Как-нибудь расскажу этот момент подробнее. Потому что тут есть варианты как PI-блок будет располагаться по отношению к CP: на внешнем интерфейсе CP один из адресов PI-блока или же весь PI-блок за одним из внутренних интерфейсов CP. Во втором случае на CE прописан маршрут для PI-блока в сторону CP.
Создание лабы
Лаба будет предельно упрощённая, чтобы проверить некоторые возможности только самого CP. Схема следующая:
Интерфейсы нужно соединить точно как на схеме. Тут 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):
и выполнить первоначальную инициализацию:
Платформа определилась как 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.
После инициализации захожу через браузер на CP ещё раз. Называется Gaia Portal и здесь можно выполнить различные настройки системы. Настраивать ничего не буду, перехожу сразу к скачиванию SmartConsole.
Запускаю SmartConsole, при первом подключении нужно установить Fingerprint:
Наконец попадаю в привычную и удобную среду:
На этом шаге для продакшена нужно зайти в свойства шлюза (двойной щелчок), 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, там можно посмотреть кто/что делал, но комментарий очень удобная штука. Бережёт время;
- Логирование надо включать на всех правилах, за исключением супернагруженных. Иначе потом буду сложности с поиском нужного трафика в логе.
Просмотр лога
Последнее что тут хотел отметить, очень удобный просмотр лога, где не только привычные src и dst:
Возможно использование логических операторов AND, OR, NOT. Кроме этого присутствует достаточное количество фильтров. Можно кликнуть два раза на строчку лога и откроется дополнительная информация. Это всё что хотел рассказать сегодня. Ссылка на гайды.
А какой пароль на чекпоинте то?
А прочитать?