Сложности перехода на отечественный NGFW, или почему наличие конвертера правил не поможет

Привет! Меня зовут Великов Павел, я архитектор по информационной безопасности в «Кросс технолоджис». Хочу поделиться интересным опытом миграции с зарубежного NGFW на Континент 4.

Введение

К нам обратился заказчик с задачей миграции с Palo Alto на отечественный NGFW. В качестве отечественного NGFW заказчик выбрал Континент 4, т.к. заказчик ранее с ним работал, и у него в эксплуатации был Континент 3 версии. Выполнение задачи миграции правил — достаточно сложный процесс, т.к. у различных производителей используется своя логика работы, которая требует аналитики и ручных «подкручиваний».

В ходе обследования текущей инсталляции NGFW была собрана следующая исходная информация: шлюзы под управлением PANOS 9 и 10 версий, на каждом из шлюзов организован RA-VPN, 3000 объектов (IP-адресов, DNS-имен), 1000 сервисов, несколько десятков URL-списков для доступа серверов и пользователей, 1000 правил фильтрации и порядка 100 правил NAT.

Правила доступа реализованы с использованием black-листов, в которых указаны запрещенные приложения, сайты и ip-адреса.

Приступаем к переносу

Проанализировав исходные данные, мы начали искать методы, которые позволят оптимизировать процесс переноса правил фильтрации с Palo Alto на Континент 4. Так как Континент 4 не имеет встроенного конвертора правил, но имеет возможность импорта сетевых объектов из CSV-файла или импорта правил/объектов из Check Point версий 77.30 и 80.20, то сначала необходимо исходные правила/объекты сконвертировать в формат правил Check Point, затем выполнить конвертацию в формат Континента. Для конвертации мы использовали утилиту SmartMove, для этого потребовалось загрузить архив, выгруженный из Panorama. Загружаем, ждём, получаем несколько файлов в том числе и файл с оптимизированными политиками. Осталось сконвертировать правила в формат Континента и готово?

Проблема №1

Первая проблема, с которой мы столкнулись уже на первом этапе конвертации — использование в качестве Source и Destination ANY. Почему же так? Потому что Palo Alto — Zone Based firewall, и заказчик активно использовал эту функцию. Как она работает? Каждому интерфейсу назначена своя зона безопасности и при прохождении трафика через Firewall проверяется не только адрес источника/назначения, но и зона безопасности.

Вот так выглядело исходное правило:

Вот так выглядит сконвертированное правило:

После конвертации правило разрешает доступ всем и везде. Разве это задумывалось? Нет, данное правило необходимо для работы приложения SkypeForBusiness при подключении через VPN-клиент (Global Protect).

Что же делать? Использовать вместо зоны VPN-клиентов пул адресов VPN-клиентов.

Проблема №2

Внимательные читатели обратили внимание, что в сконвертированных правилах отсутствует фильтрация по приложениям. У нас же не L3/L4, а межсетевой экран, поэтому требуется фильтровать не только по портам, но и по приложениям. Добавляем фильтрацию по приложениям и получаем следующее правило:

Проблема №3

При выполнении миграции решено было использовать новый RA VPN пул, т.к. на время опытной эксплуатации требовалось обеспечение удаленного доступа с использованием Global Protect и Континент АП. Неужели придётся менять объект в правилах руками? К счастью, в продукте есть встроенный сервис, который позволяет просмотреть, где используется объект и заменить его на другой. Для этого выбираем старый объект, указываем, на какой объект заменить и в каких правилах.

Переходим к следующему правилу:

Вроде бы ничем не примечательное правило — разрешение доступа до рабочей станции пользователя по RDP. Какой же сервис выбрать при переносе на Континент? И что же значит application-default в столбце Service? Это значит, что разрешено взаимодействие по портам по умолчанию, т.е. для приложения RDP разрешены порты TCP/3389 и UDP/3389. А что делать с приложениями, для которых не знаешь порты по умолчанию? Для этого в Palo Alto есть встроенная библиотека приложений, где можно найти приложение и посмотреть порты по умолчанию. Пример для ms-rdp:

Можем ли мы при переносе правила в Континенте указать в качестве Сервиса Any? Нет, потому что, во-первых, исходное правило подразумевало доступ лишь по портам по умолчанию. Во-вторых, использование правил фильтрации по приложениям без заданного сервиса ведёт к неоптимальному расходованию ресурсов, т.к. трафик по всем портам будет инспектироваться на наличие данного приложения. Поэтому рекомендуется всегда по возможности указывать сервис.

В итоге получаем следующее правило:

Следующей проблемой стало использование DNS-имён в правилах фильтрации, т.к. данный тип объектов использовать нельзя — необходимо вручную их перенести. Изучаем Release Notes к Континент 4.1.5 и обнаруживаем следующее ограничение:

Смотрим результаты конвертации и получаем цифру — 838 объектов. Т.к. превышение данного лимита может повлечь некорректную работоспособность УБ, решаем не превышать данное количество объектов и параллельно заводим пожелание на доработку с просьбой увеличить кол-во объектов DNS-имя в следующих релизах. (В дальнейшем мы обновили до Континент 4.1.7, где кол-во объектов увеличено до 1000).

Изучив объекты, которые используются заказчиком, мы понимаем, что большинство объектов — сервера со статичным IP, и решаем использовать IP-адреса для серверов, а для внешних сервисов использовать FQDN-имена.

При переносе данного типа объектов использовался встроенный механизм создания хостов, который позволяет ввести доменное имя и получить IP-адрес хоста, что ускорило процесс миграции.

URL-списки переносим вручную, т.к. ни при импорте из CSV-файла, ни при импорте из объектов Check Point этот тип объектов не переносится, а API продукта закрыт.

Перенос завершен

Объекты, сервисы перенесены, правила перенесены, проверяем — и правила URL-фильтрации не работают. Разбираемся, с чем это связано, и выясняем следующее: при обработке трафика правилом Контроля приложения данный трафик не попадёт в цепочку URL-фильтрации.

Вот так выглядит Packet Flow Континент 4:

Вот он виновник — блокировка приложений для удаленного доступа. Правило расположено одним из первых и препятствует работе механизма URL-фильтрации.

Проводим анализ исходных правил и понимаем, что требуется структуризация и упорядочивание правил для корректной работоспособности.

При разработке нового концепта правил было принято решение:

1. Использовать URL-фильтрацию для серверов, т.к. обновление ОС происходит с внутренних репозиториев для Unix-серверов и WSUS для Win-серверов, то требуется обеспечить доступ до серверов обновлений. URL-списки один из лучших способов, т.к. поддерживает указание wildcard-имён, например, *.example.com. Данное решение нам также позволило уменьшить количество использованных FQDN-объектов. Например, KSC для получения обновлений использует 83 FQDN-объекта. При лимите в 1000 объектов (для версии 4.1.7) кажется незначительным, но при лимите в 150 объектов (для версии 4.1.5) — мы ограничены в дальнейшем использовании FQDN.

2. Использовать URL-фильтрации для АРМ, которые используют для работы только браузер для выхода в Интернет на несколько веб-сайтов.

От использования URL-фильтрации для всех пользователей пришлось отказаться в пользу контроля приложений для блокировки социальных сетей, т.к. приоритетной задачей является запрет приложений удаленного доступа, которые работают по TCP/80, 443, как и http(s) трафик, а также блокировка TOR. Данный метод имеет свои недостатки, т.к. сайт не загружается, и пользователь не получает уведомление о том, что доступ к данному сайту запрещен.

В итоге был сформирован следующий концепт правил:

Согласно данному концепту, цепочки обработки трафика не пересекаются и трафик обрабатывается корректно. Структурно правила можно разделить на следующие разделы: блокировка трафика от/к вредоносных(ым) IP-адресам, правила для публикаций, правила для разграничения доступа внутри ЛВС, правила доступа в интернет.

Результаты

Подводя итоги проекта, стоит отметить, что в результате совместной работы с заказчиком удалось актуализировать и выполнить перенос правил межсетевого экранирования. В будущих версиях Континента хотелось бы увидеть открытое, задокументированное API, которое позволит автоматизировать задачи по миграции политик и объектов (DNS-имен, URL-списков), а также рассмотреть возможность реализации в продукте ведения подробной базы описания приложений с указанием портов по умолчанию, которые используются данным приложением, как это реализовано в CheckPoint или Palo Alto.