Наша почта:
В Москве:
РФ (звонок бесплатный):
DevNetOps на старте, внимание, марш! Автоматизируемый PT NGFW
{ Главный инженер PT NGFW в Positive Technologies }
Юрий Дышлевой
Видео доклада
Презентация спикера
DevNetOps на старте, внимание, марш! Автоматизируемый PT NGFW
Межсетевой экран нового поколения давно перестал быть «коробкой», которую настраивают руками через графический интерфейс. В крупной инфраструктуре счёт правил идёт на десятки и сотни тысяч, объекты создаются и удаляются ежедневно, а миграция с одного вендора на другого превращается в отдельный проект. Всё это делает межсетевой экран полноценным объектом автоматизации.
Доклад посвящён архитектуре PT NGFW с точки зрения автоматизации, работе с его API и реальным кейсам, которые возникали в пилотных проектах и в продуктивных средах.
Доклад посвящён архитектуре PT NGFW с точки зрения автоматизации, работе с его API и реальным кейсам, которые возникали в пилотных проектах и в продуктивных средах.
Архитектура комплекса
Комплекс PT NGFW состоит из трёх сущностей:
- 1.Межсетевой экран — собственно средство фильтрации;
- 2.Система централизованного управления (ЦУ) — объединяет межсетевые экраны в кластер и домен управления;
- 3.Лог-коллектор — отдельная сущность, на которую межсетевой экран складывает информацию о том, что он обработал, пропустил или заблокировал.
Автоматизировать так или иначе можно все три компонента.
Межсетевой экран существует в аппаратном и виртуальном исполнении: линейка из 10 моделей — от гигабита до тяжёлых ЦОДовских платформ на 400 Гбит/с — и 5 виртуальных версий. Виртуальные экземпляры запускаются как на VMware ESXi, так и на KVM и KVM-подобных системах виртуализации.
Принципиально важно, что с точки зрения автоматизации разницы между аппаратным и виртуальным исполнением нет. Все скрипты и все кейсы, рассмотренные ниже, применяются одинаково — отличается только производительность.
Межсетевой экран существует в аппаратном и виртуальном исполнении: линейка из 10 моделей — от гигабита до тяжёлых ЦОДовских платформ на 400 Гбит/с — и 5 виртуальных версий. Виртуальные экземпляры запускаются как на VMware ESXi, так и на KVM и KVM-подобных системах виртуализации.
Принципиально важно, что с точки зрения автоматизации разницы между аппаратным и виртуальным исполнением нет. Все скрипты и все кейсы, рассмотренные ниже, применяются одинаково — отличается только производительность.
Интерфейсы как объекты автоматизации
У типового межсетевого экрана можно выделить три типа интерфейсов:
- 1.Data plane — через них проходит полезный трафик: VLAN'ы, сети, сегменты. Для задач автоматизации интереса не представляют.
- 2.Кластерный синхроинтерфейс — межсетевой экран умеет кластеризоваться, для этого реализован собственный протокол с субсекундной сходимостью. Тема отдельная и обширная.
- 3.Management-интерфейс — именно он интересен в контексте автоматизации. Через него происходит взаимодействие с системой централизованного управления по TCP/443, а по порту 7002 межсетевой экран отправляет логи на централизованную систему логирования.
API между системой управления и самим межсетевым экраном закрыт и пока не раскрывается — для задач автоматизации он и не требуется.
Система управления как объект автоматизации
Система централизованного управления также поставляется в аппаратном и виртуальном исполнении, но здесь картина обратная относительно межсетевых экранов: если российский потребитель предпочитает аппаратные NGFW, то ЦУ в пилотах и продуктиве чаще встречается в виртуальном виде.
Под капотом это набор Docker-контейнеров, каждый из которых отвечает за свою задачу. Взаимодействие с администратором идёт по HTTPS на 443-й порт, транспорт защищён TLS 1.3.
Ключевые контейнеры для задач автоматизации — frontend и backend. Frontend — это, по сути, замена оператора: он преобразует клики в интерфейсе в машиночитаемые команды к backend — например, на создание нового объекта или правила. Ровно то же самое можно сделать самостоятельно, обращаясь к backend напрямую — скриптом или обычным curl-запросом (например, методом login).
Под капотом это набор Docker-контейнеров, каждый из которых отвечает за свою задачу. Взаимодействие с администратором идёт по HTTPS на 443-й порт, транспорт защищён TLS 1.3.
Ключевые контейнеры для задач автоматизации — frontend и backend. Frontend — это, по сути, замена оператора: он преобразует клики в интерфейсе в машиночитаемые команды к backend — например, на создание нового объекта или правила. Ровно то же самое можно сделать самостоятельно, обращаясь к backend напрямую — скриптом или обычным curl-запросом (например, методом login).
С чего начать работу с API
- Справка.Доступны два вида: online help с общим описанием работы с продуктом и встроенная интерактивная справка по API. Последняя — не просто перечень методов с описанием: она интерактивна, позволяет искать нужный метод, показывает обязательные и необязательные параметры payload и сразу отдаёт готовый sample — как в виде curl-запроса, так и в виде Python-скрипта, который система управления формирует автоматически. Запрос можно тут же выполнить и получить реальный ответ: время ответа, объём переданных данных, код 200 OK и cookie авторизации для последующих обращений.
- Панель разработчика.Первое, что стоит нажать при знакомстве с API нового устройства, — F12. В панели разработчика видно, какими именно методами frontend обращается к backend: тип запроса, код ответа, cookie, а также payload и ответ в формате JSON. PT NGFW последовательно придерживается максимально стандартных и удобочитаемых конструкций: и запрос, и ответ — структурированный JSON.
Практический пример:
попытка создать тестовый объект, который уже существует, возвращает соответствующую ошибку — обработчик запросов понимает контекст. После удаления объекта повторный запрос проходит успешно, а следующим curl-вызовом с ID созданного объекта backend формирует тестовое правило, которое сразу видно в интерфейсе.
попытка создать тестовый объект, который уже существует, возвращает соответствующую ошибку — обработчик запросов понимает контекст. После удаления объекта повторный запрос проходит успешно, а следующим curl-вызовом с ID созданного объекта backend формирует тестовое правило, которое сразу видно в интерфейсе.
Кейс 1. Нагрузочное тестирование в пилотах
Заявленные скорости — от гигабита до 400 Гбит/с — рынок регулярно просит доказать. Тестирование проводится по методике RFC 9411 (benchmarking-методика для сетевых устройств безопасности), которая хорошо ложится на класс NGFW. Основная сложность методики — отсутствие универсального стандарта на mix-трафик, поэтому используется собственный набор, опубликованный на странице продукта; при желании заказчик может протестировать решение своим набором.
Межсетевой экран никогда не работает в вакууме, поэтому поверх нагрузки намеренно накладываются дополнительные сложности: всегда включена идентификация приложений, при тестировании IPS включается IPS, при тестировании L3 задействуются виртуальные контексты.
Отдельный принципиальный момент: тест с единственным правилом permit any any — это неправильный тест. Поэтому на младшие платформы (серия 10) загружается 10 000 политик, на старшие (начиная с серии 20 и до тяжёлых 30-х) — 100 000 политик.
Здесь и помогает API. Существует репозиторий со скриптами, позволяющими автоматизировать создание объектов, сервисов и итоговых правил. Порядок действий предельно прост: скачать скрипт, подставить адрес системы централизованного управления, указать логин и пароль, задать нужное число объектов — и запустить. Консоль сообщает, какие объекты созданы; после обновления страницы объекты source и destination появляются в интерфейсе.
Показательный результат: по итогам одного из отчётов о нагрузочном тестировании выяснилось, что заявленная производительность занижена на 26 % — и это осознанная политика, чтобы заказчик мог рассчитывать на цифры, которые устройство гарантированно превзойдёт на практике.
Межсетевой экран никогда не работает в вакууме, поэтому поверх нагрузки намеренно накладываются дополнительные сложности: всегда включена идентификация приложений, при тестировании IPS включается IPS, при тестировании L3 задействуются виртуальные контексты.
Отдельный принципиальный момент: тест с единственным правилом permit any any — это неправильный тест. Поэтому на младшие платформы (серия 10) загружается 10 000 политик, на старшие (начиная с серии 20 и до тяжёлых 30-х) — 100 000 политик.
Здесь и помогает API. Существует репозиторий со скриптами, позволяющими автоматизировать создание объектов, сервисов и итоговых правил. Порядок действий предельно прост: скачать скрипт, подставить адрес системы централизованного управления, указать логин и пароль, задать нужное число объектов — и запустить. Консоль сообщает, какие объекты созданы; после обновления страницы объекты source и destination появляются в интерфейсе.
Показательный результат: по итогам одного из отчётов о нагрузочном тестировании выяснилось, что заявленная производительность занижена на 26 % — и это осознанная политика, чтобы заказчик мог рассчитывать на цифры, которые устройство гарантированно превзойдёт на практике.
Кейс 2. «Нулевой пациент»
Первым продуктивным внедрением PT NGFW стала сама Positive Technologies. Одним из ключевых требований сетевиков к продукту была интеграция с корпоративным CI/CD — и благодаря открытому развитому API это было реализовано без затруднений.
Самые востребованные методы API у инженеров-сетевиков — создание и удаление объектов, а также перемещение пользователей между группами: рутина отдаётся скриптам или первой линии поддержки.
Самые востребованные методы API у инженеров-сетевиков — создание и удаление объектов, а также перемещение пользователей между группами: рутина отдаётся скриптам или первой линии поддержки.
Кейс 3. Порог входа и ИИ
Отдельная благодарность — Евгению Олькову из TS Solution, который первым записал и выложил для сообщества курсы по PT NGFW.
Показателен сам подход: не будучи программистом, он решил задачу массового добавления объектов из файла, «скормив» ИИ справку по API и перечень нужных объектов — и получив рабочий инструмент для конкретного заказчика без участия инженера. Порог входа во взаимодействие с API сегодня крайне низкий.
Показателен сам подход: не будучи программистом, он решил задачу массового добавления объектов из файла, «скормив» ИИ справку по API и перечень нужных объектов — и получив рабочий инструмент для конкретного заказчика без участия инженера. Порог входа во взаимодействие с API сегодня крайне низкий.
Финал
Главное напутствие звучит просто: опасайтесь неведомой коробки без API. Без него невозможно решать рутину — а рутина в сетевой инфраструктуре составляет основной объём работы.
Подход API First при разработке продукта позволяет закрывать частные задачи силами самих инженеров, даже тех, кто не считает себя программистом. Порог входа сегодня крайне низок: развитая интерактивная справка, стандартные HTTPS и JSON, открытые скрипты и конвертеры, а также ИИ-инструменты делают автоматизацию доступной практически каждому сетевому инженеру.
И отдельная благодарность сообществу — за то, что оно помогает делать продукт лучше.
Подход API First при разработке продукта позволяет закрывать частные задачи силами самих инженеров, даже тех, кто не считает себя программистом. Порог входа сегодня крайне низок: развитая интерактивная справка, стандартные HTTPS и JSON, открытые скрипты и конвертеры, а также ИИ-инструменты делают автоматизацию доступной практически каждому сетевому инженеру.
И отдельная благодарность сообществу — за то, что оно помогает делать продукт лучше.
В Москве:
РФ (звонок бесплатный):
Наша почта:
GetNet
Остались вопросы?
Группа компаний VoxLink © 2011-2026