Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет! Меня зовут Великов Павел, я архитектор по информационной безопасности в «Кросс технолоджис». Хочу поделиться интересным опытом миграции с зарубежного 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-фильтрации.
Проводим анализ исходных правил и понимаем, что требуется структуризация и упорядочивание правил для корректной работоспособности.
При разработке нового концепта правил было принято решение:
Использовать URL-фильтрацию для серверов, т.к. обновление ОС происходит с внутренних репозиториев для Unix-серверов и WSUS для Win-серверов, то требуется обеспечить доступ до серверов обновлений. URL-списки один из лучших способов, т.к. поддерживает указание wildcard-имён, например, *.example.com. Данное решение нам также позволило уменьшить количество использованных FQDN-объектов. Например, KSC для получения обновлений использует 83 FQDN-объекта. При лимите в 1000 объектов (для версии 4.1.7) кажется незначительным, но при лимите в 150 объектов (для версии 4.1.5) — мы ограничены в дальнейшем использовании FQDN.
Использовать URL-фильтрации для АРМ, которые используют для работы только браузер для выхода в Интернет на несколько веб-сайтов.
От использования URL-фильтрации для всех пользователей пришлось отказаться в пользу контроля приложений для блокировки социальных сетей, т.к. приоритетной задачей является запрет приложений удаленного доступа, которые работают по TCP/80, 443, как и http(s) трафик, а также блокировка TOR. Данный метод имеет свои недостатки, т.к. сайт не загружается, и пользователь не получает уведомление о том, что доступ к данному сайту запрещен.
В итоге был сформирован следующий концепт правил:
Action | Описание | Source | Destination | Service | APP | URL | |
Правила блокировки по IP, FQDN (trust) | Deny | Блокировка вредоносных IP | Any | Malicious IP | Any | - | - |
Правила блокировки по IP, FQDN (untrust) | Deny | Блокировка вредоносных IP | Malicious IP | Any | Any | - | - |
Правила публикаций (Publications) | Allow | Правила PAT трансляции | Опционально | Обязательно | Опционально | Опционально | - |
Правила удаленного доступа | Allow | Правила для RA-VPN | User, Group or RA-VPN Pool | Только локальные сети | Опционально | Опционально | - |
Правила LAN | Allow | Только для взаимодействия с другими компонентами в рамках ЛВС | Только локальные сети/ группа AD | Только локальные сети | Опционально | Опционально | - |
Block LAN | Deny | Блокируем весь остальной трафик в ЛВС | Локальные сети | Локальные сети | Any | Any | - |
Правила доступа в интернет Outside | Allow | Доступ серверов по URL | Обязательно IP | Не локальные сети | HTTP, HTTPS | - | URL-list |
Allow | Доступ по белому URL листу для АРМ/Группы AD | Обязательно IP, группа AD | Не локальные сети | HTTP, HTTPS | - | URL-list | |
Deny | Блокировка иного трафика | Обязательно IP, группа AD | Не локальные сети | HTTP, HTTPS | - | Block ANY | |
Deny | Block Ransomware, TOR | Локальные сети | Не локальные сети | Any | Обязательно | - | |
Allow | Доступ в интернет | Локальные сети | Не локальные сети | Опционально | Опционально | - | |
Drop Any | Deny | Any | Any | Any | Any | - | - |
Согласно данному концепту, цепочки обработки трафика не пересекаются и трафик обрабатывается корректно. Структурно правила можно разделить на следующие разделы: блокировка трафика от/к вредоносных(ым) IP-адресам, правила для публикаций, правила для разграничения доступа внутри ЛВС, правила доступа в интернет.
Результаты
Подводя итоги проекта, стоит отметить, что в результате совместной работы с заказчиком удалось актуализировать и выполнить перенос правил межсетевого экранирования. В будущих версиях Континента хотелось бы увидеть открытое, задокументированное API, которое позволит автоматизировать задачи по миграции политик и объектов (DNS-имен, URL-списков), а также рассмотреть возможность реализации в продукте ведения подробной базы описания приложений с указанием портов по умолчанию, которые используются данным приложением, как это реализовано в CheckPoint или Palo Alto.
