Тестирование процесса миграции политики безопасности с решения Check Point R81.20 на NGFW Континент 4
В процессе трансформации ИТ-инфраструктуры и перехода на отечественные средства защиты информации предприятия всё чаще сталкиваются с необходимостью заменить зарубежные комплексные решения российскими межсетевыми экранами.
Процесс смены платформы межсетевого экранирования — это всегда высокий риск ошибок и существенные временные затраты. Правила безопасности на МЭ в крупных организациях формируются годами, включают тысячи объектов (сетевые объекты, сервисы, группы, домены, url, приложения и т.д.) и определенную логику формирования самих правил.
Перенос правил фильтрации и базы объектов вручную при смене межсетевого экрана — процесс не только длительный, но и крайне рискованный. Одиночные ошибки в объектах или порядке правил способны вызвать сбои в работе бизнес-сервисов или создать бреши в защите.
Для решения этой задачи и автоматизации рутинных процессов Кодом Безопасности были разработаны специализированные инструменты по работе с API Континент 4 и миграции со сторонних решений:
c4_lib — библиотека для работы с API Континент 4, который используется для поддержки связи МК-ЦУС.
c4_policy_install — инструмент для подачи ЦУС команды на установку политики через API Континент 4.
c4_config_exporter — инструмент для экспорта через API Континент 4 конфигурации УБ для сторонних compliance-систем.
c4_rules_maker — инструмент для генерации через API Континент 4 правил по заданным директивам через API Континент 4.
c4_vlan_maker — инструмент для генерации логических интерфейсов VLAN по заданному списку
c4_excel_import — инструмент для импорта правил фильтрации (FW) и правил трансляции (NAT) через промежуточный файл *.xlsm
c4_ioc_omporter_k — инструмент для импорта объектов IoC (Indicator of Compromise) от вендора Kaspersky на Континент 4.1.9 и выше.
c4_ioc_importer_rv — инструмент для импорта объектов IoC (Indicator of Compromise) от вендора Security Vision на Континент 4.1.9 и выше.
aserv_c4_importer — инструмент для переноса данных с СД Континент 3.9.4 на СД Континент 4.1.9 и выше.
c4_backup_tool — инструмент для создания и выгрузки через API Континент 4 резервной копии БД ЦУС.
c4_config_transfer — инструмент для переноса политики в ограниченном объеме между разными ЦУС через API Континент 4.
convert_с3_to_c4 — инструмент для конвертации конфигурации из контейнера *.xml Континент 3.9.3 и последующего ее импорта в Континент 4.1.7 и выше.
convert_cisco_to_c4 — инструмент для конвертации активной (running) конфигурации Cisco ASA (8.3 / 8.4 / 9.1) и последующего импорта в Континент 4.1.7 и выше.
convert_cp_to_c4 — инструмент для конвертации конфигурации из контейнеров .fws (правила) и .c (объекты) Check Point R77.30 / R80.20 и последующего ее импорта в Континент 4.1.7 и выше.
convert_cp_json_to_c4 — инструмент для конвертации конфигурации из контейнеров .json (правила) и .json (объекты) Check Point R80.X / R81.Х и последующего ее импорта в Континент 4.1.7 и выше.
convert_forti_to_c4 — инструмент для конвертации конфигурации из FortiGate 5.0.4 / 7.2.0 и последующего ее импорта в Континент 4.1.7 и выше.
convert_ug_to_c4 — инструмент для конвертации конфигурации UserGate 6.1 / 7.0 / 7.1 и последующего импорта в Континент 4.1.7 и выше.
Подробнее ознакомиться с данными инструментами и скачать их можно по ссылке на репозиторий Кода Безопасности, плюс они опубликованы на сайте производителя.
В этой статье мы разберем наш практический опыт по автоматизированному переносу политики безопасности с Check Point R81.20 на NGFW Континент версии 4.2.1.653. Для автоматизации мы использовали утилиту convert_cp_json_to_c4, которая преобразовывает JSON-выгрузку объектов и политик Check Point в формат, готовый к импорту в приложении «Менеджер Конфигурации».
В статье приводятся результаты работы с конкретными версиями решений двух производителей. В зависимости от версии возможны нюансы, но, уверены, что общая механика работ и описанные ограничения помогут сэкономить время и избежать некоторых проблем коллегам, которые столкнуться с аналогичными задачами.
Основные характеристики инструментов
1. Все инструменты представлены набором скриптов на языке Python.
2. Все инструменты предоставляют пользователю интерфейс CLI.
3. Все инструменты содержат встроенную справку по их использованию (ключи, параметры).
4. Инструменты для конвертации конфигурации поставляются в виде исходных файлов <tool>.py.
5. Инструменты для работы с API Континент 4 поставляются в файлах <tool>.tar.gz и <tool>.whl.
6. Инструменты для работы с API Континент 4 устанавливают компоненты, необходимые для выполнения своих функций.
7. Инструменты для работы с API Континент 4 используют библиотеку c4_lib.
8. Инструменты для работы с API Континент 4 рекомендуется устанавливать и запускать в виртуальном окружении.
Системные требования по работе с инструментами
1. Всем инструментам необходим интерпретатор Python последней версии (должна быть не ниже 3.9, желательно 3.11 и выше), установленный на рабочей станции пользователя.
2. Инструментам для работы с API Континент 4 необходим компонент openssl версии 3.0 или выше, установленный на рабочей станции пользователя.
3. Инструментам для работы с API Континент 4 необходим физический и логический доступ рабочей станции пользователя к ЦУС.
4. Инструментам для работы с API Континент 4 необходимо наличие IP-адреса рабочей станции пользователя в списке разрешенных для подключения к ЦУС, речь про настройки «Доступ к ЦУС» в свойствах УБ с ролью ЦУС в программе «Менеджер Конфигурации» (Рисунок 1).
5. Инструментам для работы с API Континент 4 необходимо указание учетной записи администратора Континент 4 с ролью Главный администратор. В программе «Менеджер Конфигурации» раздел «Администрирование» можно проверить роль используемой УЗ и при необходимости добавить (Рисунок 2).
6. Инструментам для работы с API Континент 4 необходима предварительная установка библиотеки c4_lib.
7. Инструментам для работы с API Континент 4 необходимо АРМ под управлением ОС Linux*. Рекомендуется использовать ОС, где есть возможность обновлять пакеты Python и Openssl до актуальных версий из официальных репозиториев, а не собирать самостоятельно из исходников, т.к. в этом случае работа утилиты не гарантируется. Процесс установки необходимого ПО значительно усложняется и появляется вероятность, что Python не будет корректно работать. К примеру, в ходе тестирования столкнулись с подобным, используя ОС Astra Linux 1.7.3. Это актуально для тех, у кого установлен ПО «Менеджер Конфигурации» с wine (Рисунок 3).
* Скрипты, которые не требуют криптографии и требует только Python, работают на Windows.
8. Список ОС Linux, на которых проверена корректная работа с API Континент 4:
Ubuntu 24.04/26.04 LTS
Debian 12/13
Kali Linux 2024
Инструкция по установке библиотеки для работы с API Континент 4*
Внимание: перед началом выполнения работ необходимо ознакомиться со списком ограничений, с которыми столкнулись на практике (см. приложение 1).
Библиотека c4_lib предназначена для обеспечения работы с API Континент 4, который используется для поддержки связи МК - ЦУС.
Основные функции:
1. Подключение к ЦУС.
2. Аутентификация и авторизация от имени администратора.
3. Выполнение функций в составе других инструментов.
Рекомендованные системные требования для установки на виртуальную машину: 2 vCPU, 8 GB RAM, 32 GB HDD.
Последовательность действий по установке библиотеки для работы с API Континент 4 на АРМ с доступом в Интернет (в случае отсутствия использовать инструкцию по оффлайн установке):
1. Установить пакеты python3 python3-openssl python3-venv: sudo apt-get install python3 python3-openssl python3-venv
2. Cоздать папку для рабочего окружения утилит, например, ~/continent4:
cd /home/admin/
mkdir continent4
3. Скачать с download.securitycode.ru или gitverse архив с библиотекой c4_lib (Рисунок 4)
4. Cкопировать в созданный каталог ~/continent4.
Создать виртуальное окружение с помощью команды:python3 -m venv --system-site-packages /home/admin/continent4
5. Активировать созданное виртуальное окружение с помощью команды:source /home/admin/continent4/bin/activate
6. Выполнить установку инструмента с помощью команды:pip3 install c4_lib-2.0.tar.gz
7. Дождаться завершения загрузки из репозиториев Python и установки компонентов, необходимых для работы инструмента.
8. После использования инструмента виртуальное окружение можно деактивировать с помощью команды deactivate: source /home/admin/continent4/bin/deactivate
Работа с инструментом для конвертации конфигурации из *.json Check Point и последующего импорта в Континент 4
Особенности работы
Конвертация конфигурации Check Point из формата .json с кодировкой UTF-8 в универсальный формат .json для последующего импорта в Континент 4 в объеме:
правила фильтрации сетевого трафика;
правила трансляции сетевых адресов;
сетевые объекты, используемые в правилах;
сервисы, используемые в правилах;
временные интервалы, используемые в правилах.
Для получения конфигурации Check Point в формате *.json необходимо использовать инструмент "Show Package Tool".
На выходе инструмента "Show Package Tool" получаются файлы двух типов:
файл в формате *.json с правилами;
файл в формате *.json с объектами.
При большом количестве правил и связанных объектов в исходной конфигурации подразумевается создание нескольких файлов в универсальном формате *.json c нумерацией в имени, исходя:
либо из заданного пользователем ограничение на количество обрабатываемых объектов;
либо из максимально допустимого количества объектов (20000), которое может быть обработано при импорте на ЦУС.
С учетом ограничения на количество обрабатываемых объектов в результате конвертации может быть создано несколько файлов в универсальном формате *.json, а именно:
несколько файлов с суффиксом -fw, содержащих правила фильтрации сетевого трафика и связанные с ними объекты;
несколько файлов с суффиксом -nat, содержащих правила трансляции сетевых адресов и связанные с ними объекты.
Вложенные правила типа Inline Layer (при наличии таковых в конфигурации Check Point) попадают в файл без номера с суффиксом -fw или -nat, соответственно, ниже будет показан пример.
Последовательность действий по получению конфигурации Check Point в формате *.json
1. Выполнить сохранение всех изменений в приложении SmartConsole и установить database на сервер управления (Рисунок 5).
2. В приложении SmartConsole для тестирования создавалась отдельная политика безопасности MAB со следующими настройками Access Control (Рисунок 6).
3. Политика MAB cодержит следующий список правил МЭ (Рисунок 7).
4. Плюс вложение по 19му правилу, созданному как Inline Layer (Рисунок 8).
5. Политика MAB cодержит следующий список правил NAT (Рисунок 9)
6. Подключиться по ssh к серверу управления Check Point и перейти в директорию $FWDIR/scripts с помощью команды: cd $FWDIR/scripts
7. Проверить наличие файла web_api_show_package.sh с помощью команды:
ls -lh | grep web_api (Рисунок 10)
8. Запустить скрипт с помощью команды: ./web_api_show_package.sh (Рисунок 11)
9. Выгрузить созданный архив с помощью WinSCP на рабочую станции пользователя (Рисунок 12).
Примечание: если возникают проблемы с подключением по WinSCP, то необходимо сменить оболочку на bash для УЗ, с помощью команды: chsh -s /bin/bash <username>
10. Пример содержимого архива данной политики на рисунке 13.
Как можно видеть, архив содержит файлы в формате *.json с правилами NAT, МЭ и сетевыми объектами. Плюс для правила Inline Layer есть отдельный файл MAB-Management, имя для которого формируется исходя из его названия в SmartConsole.
11. Если открыть HTML-версию этих файлов, то на рисунке 14,15 и 16 увидим следующего формата содержимое правил:
12. Сетевые объекты имеют следующий вид, на примере объекта типа – host (Рисунок 17).
Последовательность действий по использованию инструмента convert_cp_json_to_c4 на ОС Linux
1. Скачать с download.securitycode.ru или gitverse файл convert_cp_json_c4.py
2. Cкопировать в созданный ранее каталог ~/continent4.
3. Разархивировать архив "show_package.."полученный на этапе ранее в созданный ранее каталог ~/continent4.
4. Перейти в директорию папки:
cd /home/admin/continent4/show_package-2026..
5. Для вызова встроенной справку по использованию инструмента convert_cp_json_to_c4 выполнить команду: python3 /home/admin/continent4/convert_cp_json_to_c4.py
6. Ознакомиться с её содержанием (Рисунок 18)
7. Примеры использования инструмента:
a) Для конвертации политики МЭ требуется указать файл с сетевыми объектами и правилами МЭ используется следующего вида команда:
python3 /home/admin/continent4/convert_cp_json_to_c4.py -i MAB_objects.json MAB\ Network-Management\ server.json -o /home/admin/continent4/ --name MAB_AccessPolicy
b) Для конвертации политики NAT требуется указать файл с сетевыми объектами и правилами NAT используется следующего вида команда:
python3 /home/admin/continent4/convert_cp_json_to_c4.py -i MAB_objects.json MAB\ NAT-Management\ server.json -o /home/admin/continent4/ --name MAB_NAT
c) Для конвертации вложенной политики требуется указать файл с сетевыми объектами и правилом «Inline Layer» используется следующего вида команда:
python3 /home/admin/continent4/convert_cp_json_to_c4.py -i “MAB_objects.json” “MAB-Management server.json” -o /home/admin/continent4/ --name InlineLayer_MAB
8. Подробности по возникшим ошибкам можно посмотреть в логах выполнения запущенного инструмента. Так можно понять, какие правила или объекты не перенеслись. Также указывается кол-во правил, которое было перенесено в выходной файл (Рисунок 22).
Последовательность действий по использованию инструмента convert_cp_json_to_c4 на ОС Windows*
Примечание: скрипты, которые не требуют криптографии, API Континент 4 и необходим только Python, работают на Windows.
1. Выполнить установку Python c помощью офф. установщика или через Microsoft Store.
2. Открываем терминал CMD и проверяем, что Python установлен с помощью команды python –version
3. Создаем виртуальное окружения в Python предварительно перейдя в директорию проекта и выполнить команду:python –m venv cont4
В этой команде cont4— это название виртуального окружения.
4. Активировать созданное ранее виртуальное окружение с помощью команды: cont4\Scripts\activate
5. Разархивировать архив show_package.., полученный на этапе ранее в созданный ранее каталог ~/cont4.
6. Скачать с download.securitycode.ru или gitverse файл convert_cp_json_c4.py и копируете в созданный ранее каталог ~/cont4.
7. Перейти в директорию show_package..
cd C:\Users\User\cont4\show_package-2026..
8. Для вызова встроенной справки по использованию инструмента convert_cp_json_to_c4 выполнить команду:
python C:\Users\User\cont4\convert_cp_json_to_c4.py
9. Ознакомиться с её содержанием
10. Примеры использования инструмента:
a) Для конвертации политики требуется указывать файл с сетевыми объектами и правилами МЭ используется следующего вида команда:
python C:\Users\User\cont4\convert_cp_json_to_c4.py -i “MAB_objects.json” “MAB Network-Management server.json” -o C:\Users\User\cont4\ --name MAB_AccessPolicy
b) Для конвертации политики требуется указывать файл с сетевыми объектами и правилами NAT используется следующего вида команда:
python convert_cp_json_to_c4.py -i “MAB_objects.json” “MAB NAT-Management server.json” -o C:\Users\User\cont4\ --name MAB_NAT
c) Для конвертации политики требуется указывать файл с сетевыми объектами и правилом Inline Layer используется следующего вида команда:
python convert_cp_json_to_c4.py -i “MAB_objects.json” “MAB-Management server.json” -o C:\Users\User\cont4\ --name InlineLayer_MAB
11. Подробности по возникшим ошибкам можно посмотреть в логах выполнения запушенного инструмента. По ним можно понять, какие правила или объекты не перенеслись и также указывается кол-во правил, которое было перенесено в выходной файл (Рисунок 30).
Последовательность действий по импорту политики на Континент 4
1. Запустить приложение «Менеджер Конфигурации». Убедиться, что выполнено сохранение всех изменений и установлена политика на ЦУС. Также рекомендуется создать резервную копию и экспортировать её из «МК» перед импортом сторонней политики.
2. Для импорта политики перейти в раздел «Межсетевой экран» и нажать на «Импортировать» (Рисунок 31).
3. В открывшемся окне выбрать файл для импорта из внешней системы в формате *.json (Рисунок 32).
4. Начнется процесс импорта правил фильтрации.
5. По завершению процесса отобразиться информационное окно с результатами импорта,
a) пример для импорта, который выполнен с предупреждениями;
b) без ошибок.
6. На рисунке 36 показано, как выглядит перенесенная политика трансляции.
7. Как выглядит перенесенная политика фильтрации.
8. Плюс правила из Inline Layer, которые импортировались отдельным файлом.
9. В разделе «Задачи» можно ознакомиться с отчетом об импорте политики, ниже примеры отображения информации.
Приложение 1. Результаты и ограничения, с которыми столкнулись в ходе тестирования
Для правил фильтрации
Все импортированные правила на ЦУС в приложении «Менеджер Конфигурации» будут отображаться, как отключение вне зависимости от оригинального значения параметра Enabled в Check Point. После необходимо их включать вручную (Рисунок 41).
2. При импорте правил из Check Point в Континент 4 не осуществляется перенос правил фильтрации, если в результате конвертации в столбцах в Source, Destination и Service будут установлены значения «Любой».
3. При импорте правил из Check Point в Континент 4 не осуществляется перенос правил фильтрации, которые будут являться дубликатом существующего по содержанию в Source, Destination и Service, о чем будет соответствующее указание в отчете (Рисунок 42).
4. Если в качестве Source на стороне Check Point не указано ни одного сетевого объекта, то на стороне Континент 4 для «Отправителя» будет установлено значение «Любой».
5. Если в качестве Destination на стороне Check Point не указано ни одного сетевого объекта, на стороне Континент 4 для «Получателя» будет установлено значение «Любой».
6. При импорте правил из Check Point в Континент 4 не осуществляется перенос объектов Access Role, на стороне Континент 4 для «Отправителя» будет установлено значение «Любой».
7. При импорте правил из Check Point в Континент 4 не осуществляется перенос сетевых объектов, тип которых отличается от host / network / address-range / group и на стороне Континент 4 для них будет установлено значение «Любой».
Также это касается объектов Group with Exclusion, Dynamic Object, Domain и Updatable Objects (Рисунок 43).
Еще стоит обратить внимание, что это касается и таких объектов, как Check Point Host/Gateway/Cluster, но если они будут в составе группы, то такая группа будет перенесена, но содержимое окажется пустыми.
8. Если в качестве Service на стороне Check Point не указано ни одного объекта, на стороне Континент 4 для «Сервиса» будет установлено значение «Любой».
9. При импорте правил из Check Point в Континент 4 не осуществляется перенос сервисов с типом Application/Site, на стороне Континент 4 для «Сервиса» будет установлено значение «Любой».
10. При импорте правил из Check Point в Континент 4 не осуществляется перенос сервисов с типом DCE/RPC (Distributed Computing Environment / Remote Procedure Calls) или icmpv6.
11. При импорте правил из Check Point в Континент 4 не осуществляется перенос других сервисов с протоколами 0 / 41 / 43 / 44 / 45 / 46 / 50 / 51 / 58 / 59 / 60.
12. При импорте правил из Check Point в Континент 4 не осуществляется перенос ICMP сервисов если их тип и код не входят в список поддерживаемых.
13. При импорте правил из Check Point в Континент 4 параметр «Действие» / Action переносится согласно следующим правилам:
если в качестве Action на стороне Check Point указано значение Accept, на стороне Континент 4 для «Действия» будет установлено значение «Пропустить»;
если в качестве Action на стороне Check Point указано значение Reject, на стороне Континент 4 для «Действия» будет установлено значение «Отбросить»;
если в качестве Action на стороне Check Point указано значение Drop, на стороне Континент 4 для «Действия» будет установлено значение «Отбросить».
14. При импорте правил из Check Point в Континент 4 не осуществляется перенос правил фильтрации, действие которых отличается от accept / reject / drop, такие действия, как Ask, Inform, User Auth и Client Auth (Рисунок 44).
15. Если в качестве Time на стороне Check Point не указано ни одного объекта, на стороне Континент 4 для «Временного интервала» будет установлено значение «Всегда».
16. При импорте правил из Check Point в Континент 4 не осуществляется перенос временных объектов с типом time-group.
17. При импорте правил из Check Point в Континент 4 не осуществляется перенос временных объектов, содержащих значение месяца и порядкового дня месяца в качестве старта или окончания временного интервала (Рисунок 45).
18. При импорте правил из Check Point в Континент 4 не осуществляется перенос временных объектов, содержащих значение месяца и порядкового дня месяца в качестве периода повторения работы временного интервала (Рисунок 47).
19. При импорте правил из Check Point в Континент 4 параметр Track / «Лог» (Log) переносится согласно следующим правилам:
если в качестве Track на стороне Check Point указано значение None, на стороне Континент 4 не будет автоматически включено логирование работы правила (логирование выключено);
если в качестве Track на стороне Check Point указано значение Alert, на стороне Континент 4 будет автоматически включено логирование работы правила;
если в качестве Track на стороне Check Point указано значение Snmp, на стороне Континент 4 будет автоматически включено логирование работы правила;
если в качестве Track на стороне Check Point указано значение Mail, на стороне Континент 4 будет автоматически включено логирование работы правила;
если в качестве Track на стороне Check Point указано значение User alert 1, на стороне Континент 4 будет автоматически включено логирование работы правила;
если в качестве Track на стороне Check Point указано значение User alert 2, на стороне Континент 4 будет автоматически включено логирование работы правила;
если в качестве Track на стороне Check Point указано значение User alert 3, на стороне Континент 4 будет автоматически включено логирование работы правила (Рисунок 48).
20. При импорте правил из Check Point в Континент 4 не осуществляется перенос правил фильтрации, если в качестве Track на стороне Check Point включено логирование работы правила, а также активирован чекбокс Accounting (Рисунок 49).
21. При импорте правил из Check Point в Континент 4 не осуществляется перенос правил фильтрации, имеющие вложенные слои типа Inline Layer.
22. При импорте правил из Check Point в Континент 4 перенос вложенных правил фильтрации осуществляется отдельно от основных правил фильтрации, как показано в примерах использования инструмента convert_cp_json_c4.py
23. При импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Hits;
VPN;
Content.
24. При импорте правил из Check Point в Континент 4 будут добавлены следующие необходимые для корректной работы системы параметры (для этих параметров на стороне Континент 4 будут установлены значения по умолчанию):
Профиль Web/FTP фильтрации;
Приложение;
СОВ.
25. Для сетевых объектов типа host при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
IPv6 address;
NAT;
Advanced (SNMP);
Servers cоnfiguration.
26. Для сетевых объектов типа network при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Broadcast address;
Network address (IPv6);
Prefix (IPv6);
NAT.
27. Для сетевых объектов типа address-range при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
First IPv6 address;
Last IPv6 address;
NAT.
28. Для сервисов типа tcp / udp при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Enable for TCP resource;
Match for Any;
Virtual session timeout;
Aggressive Aging;
Cluster and synchronization.
29. Для сервисов типа other при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Protocol type;
Match;
Action;
Accept Peplies;
Virtual session timeout;
Aggressive Aging;
Cluster and synchronization.
30. Для сервисов типа icmp при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Protocol type.
Для правил трансляции
Все импортированные правила на стороне Континент 4 будут отключены вне зависимости от установленного значения параметра Disabled в Check Point.
В описании каждого правила будут отражены следующие параметры:
описание объекта системы из Check Point;
значения параметров, которые не переносятся из Check Point в Континент 4 или каким либо-образом трансформируются;
информация о наличии связей между объектами системы и сетевыми устройствами.
Если в качестве Source (Original) на стороне Check Point не указано ни одного сетевого объекта, на стороне Континент 4 для "Отправителя (Исходный пакет)" будет установлено значение «Любой» / Any.
Если в качестве Destination (Original) на стороне Check Point не указано ни одного сетевого объекта, на стороне Континент 4 для "Получателя (Исходный пакет)" будет установлено значение «Любой» / Any.
При импорте правил из Check Point в Континент 4 не осуществляется перенос сетевых объектов, тип которых отличается от host / network / address-range / group.
Не осуществляется перенос правил, содержащих инвертированные сетевые объекты в качестве значения Source (Original) и/или Destination (Original).
Если в качестве Service (Original) на стороне Check Point не указано ни одного объекта, на стороне Континент 4 для «Сервиса (Исходный пакет)» будет установлено значение «Любой» / Any.
При импорте правил из Check Point в Континент 4 не осуществляется перенос сервисов с типом DceRpc или icmpv6.
При импорте правил из Check Point в Континент 4 тип трансляции переносится согласно следующим правилам:
если на стороне Check Point значения Source (Original), Destination (Original) и Service (Original) соответственно равны значениям Source (Translated), Destination (Original), Service (Translated), на стороне Континент 4 для «Трансляция» будет установлено значение «Не транслировать»/ No NAT;
если на стороне Check Point значения Source (Original) и Source (Translated) между собой не равны и значения Destination (Original) и Destination (Translated) равны, на стороне Континент 4 для «Трансляция» будет установлено значение «Отправителя» / Source;
если на стороне Check Point значения Destination (Original) и Destination (Translated) не равны и значения Source (Original) и Source (Translated) между собой не равны, на стороне Континент 4 для «Трансляция» будет установлено значение «Получателя» / Destination.
10. Не осуществляется перенос правил, для которых на стороне Check Point значения Source (Original) и Source (Translated) между собой не равны и значения Destination (Original) и Destination (Translated) между собой не равны.
11. Не осуществляется перенос правил, для которых на стороне Check Point значение Service (Original) равно ANY и значение Service (Translated) не равно ANY.
12. Если в качестве Service (Translated) на стороне Check Point не указано ни одного объекта на стороне Континент 4 для «Сервиса (Преобразованный пакет)» будет установлено значение «Любой» / Any.
13. Не осуществляется перенос правил, для которых на стороне Check Point значения Service (Original) содержит протокол, который отличается от 6 (TCP) или 17 (UDP).
14. Не осуществляется перенос правил, для которых на стороне Check Point значения Service (Translated) содержит протокол, который отличается от 6 (TCP) или 17 (UDP).
15. Для сетевых объектов типа host при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
IPv6 address;
NAT;
Advanced (SNMP);
Servers cоnfiguration.
16. Для сетевых объектов типа network при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Broadcast address;
Network address (IPv6);
Prefix (IPv6);
NAT.
17. Для сетевых объектов типа address-range при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
First IPv6 address;
Last IPv6 address;
NAT.
18. Для сервисов типа tcp / udp при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Enable for TCP resource;
Match for Any;
Protocol type;
Virtual session timeout;
Aggressive Aging;
Cluster and synchronization.
19. Для сервисов типа other при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Protocol type;
Match;
Action;
Accept Peplies;
Virtual session timeout;
Aggressive Aging;
Cluster and synchronization.
20. Для сервисов типа icmp при импорте правил из Check Point в Континент 4 не осуществляется перенос следующих параметров:
Color;
Protocol type.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.