Пилот Palo Alto PA-3200 Series: мониторинг без риска

Задача пилота: увидеть трафик и не повлиять на сеть

Пилот без риска - это когда вы получаете честную картину реального трафика и будущих правил, но не создаете новых точек отказа. NGFW наблюдает, считает и записывает, а не принимает решения, от которых зависит доступ к сервисам. В пилоте на Palo Alto PA-3200 Series недопустимы ситуации, которые могут остановить бизнес или повредить данные.

Обычно к недопустимым относят:

• простой критичных систем (почта, ERP, телефония, VDI, госинформационные сервисы)
• скрытую деградацию (рост задержек, разрывы сессий, проблемы с MTU)
• случайные блокировки из-за сырых правил или неверной идентификации приложений
• потерю видимости (часть трафика не попала в мониторинг, выводы ошибочные)
• изменения, которые сложно быстро откатить

Почему в начале важнее наблюдать, чем блокировать: первые недели почти всегда показывают неожиданные зависимости. Например, бухгалтерия работает через привычное приложение, но внутри оно обращается к лиценз-серверу по нестандартному порту, а обновления тянет из облака. Если сразу включить запреты, вы узнаете об этом по звонкам в поддержку, а не по аккуратному отчету.

Пилот должен ответить на базовые вопросы: какие приложения реально используются, кто их запускает, между какими сегментами идут потоки, какие сервисы критичны и какие окна работ допустимы. Важно увидеть и "шум": сканирования, ошибочные DNS-запросы, старые протоколы, трафик админки.

Итог пилота - не "мы поставили железку", а пакет артефактов: отчет по видимости трафика, черновик политики (разрешения и запреты с обоснованием), перечень исключений для критичных сервисов и понятный план cutover с откатом и ответственными.

Подготовка до подключения: схема, роли, базовая линия

Перед стартом пилота важно договориться не про настройки, а про исходные данные. Если вы не знаете, где и какой трафик реально можно снять, вы соберете красивые логи, но они не ответят на вопросы бизнеса и ИБ.

Начните со схемы сети в практичном виде: где ядро, где периметр, есть ли DMZ, как подключены филиалы, какие есть интернет-каналы и резервирование. Отдельно отметьте точки, где возможен TAP или SPAN, и проверьте ограничения: скорость порта, вероятность потерь на SPAN, поддержка нужных VLAN, зеркалирование в обе стороны.

Затем назначьте роли и контакты на время пилота. Лучше один владелец на домен ответственности и понятный канал связи на инциденты:

• сеть: SPAN/TAP, VLAN, маршрутизация, изменения на коммутаторах
• ИБ: ожидания по контролю приложений, угрозам, требованиям к логированию
• владельцы сервисов: критичные приложения, окна работ, допустимые риски
• NOC/дежурная смена: мониторинг, первичная реакция, эскалация

До подключения зафиксируйте базовую линию на текущей инфраструктуре: типичные задержки и потери (в рабочие часы и ночью), загрузку каналов, число одновременных сессий и пики. Выберите 3-5 критичных проверок (например, вход в ERP, доступ к почте, VPN пользователей, вызовы в контакт-центре) и запишите ожидаемое время отклика.

Отдельно подготовьте план отката даже для режима наблюдения: кто и как отключает зеркалирование, сколько времени это занимает, какое окно допустимо, и какие признаки считаются причиной остановки пилота. Пример: если после включения SPAN на ядре появляются ошибки на портах или растет потеря пакетов, пилот ставится на паузу и точка съема меняется.

Сценарий включения в режиме мониторинга (TAP или SPAN)

Для пилота важно получить реальную картину трафика, но не стать точкой отказа. Поэтому стартуйте с пассивного подключения: NGFW видит пакеты и пишет логи, но не участвует в пересылке.

TAP и SPAN решают одну задачу, но качество данных разное. TAP чаще удобнее: он копирует трафик на физическом уровне и меньше зависит от настроек коммутатора. SPAN (mirror) проще включить, но он может отбрасывать пакеты при перегрузке и не всегда корректно передает VLAN-теги и ошибки на линии.

Выбор точки подключения зависит от цели:

• для периметра логичнее зеркалировать трафик рядом с интернет-шлюзом
• для сегментации и "восток-запад" - на агрегации или на стыке ядро/распределение
• стык между маршрутизатором и коммутатором полезен, когда важны L3-потоки конкретного узла, но там чаще встречается асимметрия

Практичный сценарий мониторинга на PA-3200:

• выделите отдельные интерфейсы NGFW под прием копии трафика (без L3-адресов и без участия в маршрутизации)
• настройте TAP или SPAN так, чтобы копия приходила только на эти порты
• создайте отдельную зону типа tap/monitor и направьте трафик в нее
• убедитесь, что устройство не отправляет пакеты обратно в сеть (без физических "петель" и без L2 bridge)
• ограничьте объем зеркалирования фильтром (VLAN, подсеть, нужный uplink), чтобы не забить SPAN

Перед стартом сбора логов проверьте четыре вещи.

Во-первых, симметрию: видит ли NGFW оба направления одной сессии. Иначе часть приложений распознается неверно.

Во-вторых, неполные потоки: на SPAN возможны пропуски, и это нужно учитывать в выводах.

В-третьих, перегруз SPAN-порта: следите за drop на коммутаторе и пиками трафика.

В-четвертых, VLAN-теги: если они не сохраняются, сегменты "смешаются" и отчеты будут ошибочными.

Такой режим дает наблюдения без влияния на прохождение пакетов и помогает подготовить правила для последующего инлайн-переключения.

Базовая настройка PA-3200 перед сбором логов

Перед сбором логов настройте PA-3200 так, чтобы им было безопасно управлять и чтобы он давал корректную картину. В пилоте важны не только пакеты, но и отсутствие новых рисков из-за доступа к устройству.

Разделите интерфейсы по смыслу: отдельный порт для управления и отдельные порты для мониторинга (под TAP/SPAN). Управляющему интерфейсу задайте адрес в выделенной админской подсети или через отдельный VLAN, без маршрутизации в пользовательские сегменты. Доступ к управлению разрешайте только с конкретных IP администраторов, а не "со всей сети".

Проверьте время и синхронизацию. Для анализа инцидентов и проектирования правил важно, чтобы логи NGFW, коммутаторов и серверов совпадали по времени. Включите NTP, задайте единый timezone и проверьте, что метки времени в Traffic и Threat совпадают с вашим SIEM или хотя бы с журналами доменных контроллеров.

Минимум, который стоит сделать до старта:

• настроить Management IP, шлюз и DNS; ограничить доступ по IP и протоколам (HTTPS, SSH)
• включить NTP и выставить timezone; проверить синхронизацию
• создать отдельные учетные записи: админ, оператор просмотра логов, аудит (только чтение)
• включить журналирование действий администраторов и хранение логов локально хотя бы на время пилота
• продумать именование интерфейсов и зон (например, Z-Users, Z-Servers, Z-DC, Z-Guest)

Зоны и имена лучше заложить сразу, даже если устройство пока не в инлайне. Если SPAN приходит "с агрегации" и вы называете зону просто "SPAN1", то при переходе в инлайн придется переделывать правила и отчеты. Если же вы сразу привяжете мониторинговый интерфейс к будущей зоне (например, "Z-Users"), проектирование политик по логам будет проще.

Набор логов для пилота: что включить и что в них смотреть

Цель пилота в мониторинге простая: собрать доказательства, какие правила понадобятся, и понять риск, не трогая трафик. Заранее договоритесь, какие логи считаются обязательными, где они хранятся и кто их ежедневно просматривает.

Traffic: основа для будущих правил

В Traffic-логах важнее не количество событий, а правильные поля. Они показывают, что реально живет в сети и что сломается при первом же запрете. Для отчета обычно достаточно регулярно выгружать и просматривать:

• app и app-category: что распознается как приложения, а что остается unknown или incomplete
• src/dst, zone и interface: откуда и куда ходят потоки, где логичнее ставить границы правил
• user (если есть интеграция с каталогом): кто и какие группы создают рискованный трафик
• bytes и session duration: "тяжелые" потоки, которые могут потребовать исключений
• session end reason: маркер проблем с путями, таймаутами и асимметрией

Пример: видно, что бухгалтерия (user/group) регулярно работает с облачной CRM, но приложение определяется нестабильно и часть сессий завершается таймаутом. Это сигнал заранее продумать правила, DNS и будущую политику дешифрования, а не ждать инлайна.

Threat, URL и DNS: отделяем шум от реальных рисков

В Threat-логах в пилоте критичнее всего не единичные вспышки, а повторяемость и привязка к конкретным хостам. Отмечайте то, что требует реакции еще до инлайна: high/critical severity, повторяющиеся попытки эксплуатации с одного источника, командные каналы и явные malware-срабатывания на популярных протоколах.

Шум чаще всего дают сканирования, рекламные домены, некорректные IoT-устройства и устаревшие агенты. Практичный подход простой: сначала подтверждаем, что трафик повторяется и относится к вашим активам, и только потом планируем блок.

Для URL-видимости смотрите категории, которые реально используются в рабочее время, и неожиданные категории изнутри сети. По DNS полезно отслеживать частые запросы, NXDOMAIN и новые домены с короткой историей.

Отдельно включите System и Config логи: они нужны, чтобы увидеть перегрузки, перезапуски процессов, изменения политик и кто их вносил. Если позже планируется SSL-дешифрование, заранее соберите базовые цифры: долю TLS-трафика, популярные SNI/домены и приложения, которые часто ломаются при inspection (банки, медсистемы, обновления).

Оценка и проектирование правил по логам

Когда PA-3200 работает в мониторинге, цель - не угадать правила, а собрать факты. Делайте выводы по окну 7-14 дней: так вы увидите будни, пики, ночные бэкапы и редкие, но важные потоки. Один день почти всегда обманывает.

Начните с понятного разреза: топ приложений, топ направлений (зоны, подсети, серверные сегменты), топ пользователей или сервисных аккаунтов и топ сессий по объему. Это и есть скелет будущей политики.

Как превратить логи в черновик правил

Удобнее идти от широкого к точному и фиксировать каждое допущение:

• соберите черновые разрешающие правила для критичных маршрутов (например, пользователи -> почта, филиалы -> ERP, серверы приложений -> БД), без попытки сразу "ужать" всё
• заменяйте обобщения на App-ID там, где он уверен (конкретное приложение вместо tcp/443), добавляйте ограничения по зонам, адресам и пользователям
• вводите точечные запреты для явно лишнего (админ-доступы из пользовательских сетей, несанкционированные удаленные утилиты) и для того, что выглядит как риск по Threat
• для спорного используйте временные исключения с причиной и сроком (например, тег TEMP-14D + комментарий, владелец сервиса)
• отдельно помечайте правила, которые требуют согласования с бизнесом: ограничения SaaS, внешних интеграций, обновлений, EDI, телефонии, видеоконференций

С "неизвестными" приложениями работайте отдельно. Если App-ID дает слишком общий результат (например, ssl или web-browsing), проверьте, хватает ли данных для идентификации, не маскируется ли трафик (туннели, прокси), и уместна ли расшифровка там, где это допустимо. Иногда идеального App-ID не будет (CDN, универсальные клиенты). Тогда правило лучше строить по назначению: сервер, домен, сегмент, пользователь.

Пример: видно регулярный ночной трафик из подсети бухгалтерии в облако на tcp/443. По логам это "ssl", но по адресатам и расписанию похоже на обмен с оператором ЭДО. Такое правило лучше сразу отметить как требующее подтверждения владельца процесса и оставить временное разрешение до согласования, вместо резкого запрета.

Контроль стабильности: метрики и здоровье устройства

Даже в мониторинге пилот может "поплыть" из-за перегрузки, потери зеркалирования или слишком шумных логов. Важно доказать не только корректность будущих правил, но и то, что устройство стабильно видит трафик в реальных пиках.

Следите за производительностью и ростом таблиц. Нагрузка должна быть предсказуемой: без резких скачков CPU, без постоянного роста сессий и без упора в лимиты dataplane.

Метрики, которые стоит проверять ежедневно (и в моменты пиков):

• CPU management plane и dataplane, признаки перегруза dataplane (очереди, задержки обработки)
• количество активных сессий и скорость их создания
• PPS и throughput по интерфейсам, рост таблиц (ARP/route, session table), скорость записи логов
• дропы на интерфейсах и причины дропов (переполнения буферов, ошибки, oversubscription)
• заполнение диска/лог-хранилища и задержки доставки логов в SIEM (если используете)

Отдельно проверьте, не теряется ли видимость из-за SPAN/TAP. SPAN часто режет трафик при перегрузке порта коммутатора или при неверной настройке (например, зеркалирование нескольких источников в один узкий порт). Сравнивайте счетчики входящих пакетов на источнике и на порту зеркала и смотрите, не "пропадают" ли целые типы трафика в часы пиков.

Пики и редкие события не видно по "среднему" дню. Захватите хотя бы один цикл: ночные бэкапы, окна платежей, закрытие дня, массовые отчеты, обновления ОС. Если в эти моменты растут PPS и сессии, но дропов нет и ресурсы держатся, это хороший признак.

На время пилота настройте простые оповещения: рост CPU/сессий выше порога, появление дропов на мониторинговом интерфейсе, заполнение диска, остановка записи логов, недоступность управления. Тогда деградация не останется тихой, и вы не сделаете выводы по неполному трафику.

Пример сценария: пилот в сети с филиалами и критичными сервисами

Организация: центральный офис, 6 филиалов, связь по IPsec VPN, выход в интернет через периметр в ЦОД. Критичные сервисы: корпоративная почта, доступ к гос-системам, бухгалтерия и банк-клиент. Ошибка в правилах легко остановит работу, поэтому пилот делаем без влияния на трафик.

Сценарий подключения простой: на периметре настраиваем SPAN/TAP с внешнего и внутреннего интерфейса пограничного маршрутизатора (или коммутатора), а для филиального трафика делаем отдельное зеркалирование с интерфейса, где терминируются VPN-туннели. Так вы видите и интернет, и межфилиальные потоки, не разрывая существующие маршруты.

Через 3-5 рабочих дней обычно всплывает то, чего нет в схемах: неожиданные приложения в рабочее время, теневые облака, устаревшие протоколы и шифры, массовый RDP/SSH из офисных подсетей, трафик к гос-системам с нестандартных узлов.

Дальше важнее не пытаться сразу написать идеальную политику, а собрать короткий пакет на согласование: какие потоки нужны бизнесу, какие подозрительны, какие требуют исключений.

Практичный формат результата:

• "разрешить": приложение + источник/назначение + пользователь/группа (если есть) для почты, бухгалтерии, гос-систем
• "разрешить с условиями": только через прокси, только по времени, только из подсети терминалов
• "запретить": теневые облака, несанкционированные удаленные доступы
• исключения: устаревшие протоколы только для конкретного сервера и только временно
• вопросы к владельцам сервисов: что это за хост, зачем этот порт, кто ответственный

Так пилот превращается в управляемый план: что включаем сразу при переходе в инлайн, а что оставляем на второй этап с отдельным окном изменений.

Критерии готовности к переключению в инлайн

Переключение NGFW в инлайн - это не "нажали кнопку и смотрим". Заранее зафиксируйте критерии, чтобы решение было спокойным и проверяемым.

Минимальный набор критериев готовности

• Функциональные: основные потоки покрыты явными правилами, исключения оформлены и объяснимы, нет слепых зон (непонятных источников, сегментов, приложений).
• Риск-критерии: подтвержден план отката (кто, что и за сколько минут делает), есть тестовый план на окно работ и согласованные ответственные с контактами.
• Операционные: настроен мониторинг устройства и каналов, есть алерты на ключевые события, понятна процедура реагирования (кто смотрит логи, кто меняет правила, кто подтверждает откат), включено журналирование действий администраторов.
• Пользовательские: по итогам тестов нет влияния на критичные сервисы по доступности и скорости, а жалобы пользователей воспроизводятся и объясняются, а не выглядят как хаотичные "то работает, то нет".
• Технические: выбрана и протестирована инлайн-схема (L2/L3, VR, ECMP и т.п.), понятно где будет точка отказа и как она снимается (резервирование, байпас, кластер), подтверждена совместимость с существующей маршрутизацией и сетевой защитой.

Чтобы критерии были измеримыми, заранее договоритесь о порогах: доля трафика, которая попадает в правила без временных allow any, количество новых приложений в логах за сутки, число срабатываний Threat для разрешенных сервисов, время разбора одного инцидента.

Гейт перед инлайном на одно окно работ

Перед переключением удобно пройти короткую проверку:

1. на тестовом окне прогнать список бизнес-сценариев (5-10 действий, которые точно должны работать)

2. убедиться, что на время работ есть доступы к консоли/управлению и понятный канал связи с дежурными

3. подтвердить, что правила повторяемы: описание, владелец, срок пересмотра

4. провести репетицию отката на стенде или на менее критичном сегменте

5. зафиксировать, какие логи и метрики проверяются в первые 15, 60 и 240 минут после включения

Если хотя бы один пункт спорный, лучше задержать инлайн на неделю, чем получить простой и срочные "временные разрешения", которые потом остаются навсегда.

Частые ошибки пилота и как их избежать

Частая проблема в том, что пилот выглядит тихо и безопасно, а решения принимаются по данным, которые не отражают реальный трафик. Это особенно заметно, когда пилот делают на SPAN и сразу пишут правила "по логам".

Типичная история: на зеркальном порту не видно части сессий к критичному сервису, поэтому правило кажется лишним. После перевода в инлайн появляются разрывы, потому что в бою трафика больше и он другой.

Ошибки, которые встречаются чаще всего:

• Полагаться на неполный SPAN. Проверьте, тянет ли коммутатор зеркалирование под пиковую нагрузку. Сравните объем трафика по счетчикам на источнике и на SPAN, отслеживайте дропы и ошибки. По возможности используйте TAP там, где критична точность.
• Делать блокировки слишком рано. На старте держите политики в режиме разрешения с логированием, а блокировки вводите только после проверки с владельцами сервисов. Если нужно быстро снизить риск, начните с узких запретов для явно вредоносного.
• Игнорировать асимметрию и NAT. В мониторинге часть потоков может быть видна только в одну сторону, а адреса уже трансформированы. Потом правила не совпадают с реальностью. Проверьте симметрию маршрутов, где происходит NAT, и сверяйте логи с точки, где будет стоять NGFW.
• Смешивать тестовые и боевые изменения. Любое изменение фиксируйте дисциплинированно: отдельные окна, комментарии к правилам, обязательная проверка журналов конфигурации, чтобы потом не гадать, что изменилось.
• Недооценивать согласование исключений. На пилоте исключений почти всегда больше, чем кажется. Назначьте владельцев систем и договоритесь о сроках ответа и форме заявки, иначе пилот застрянет на спорных доступах.

Если видите потери в зеркалировании, неоднозначные сессии из-за асимметрии или хаос в изменениях, лучше остановиться и навести порядок. Это дешевле, чем чинить простои после переключения.

Короткий чеклист и следующие шаги после пилота

Чтобы пилот дал понятный результат и не превратился в "сбор логов ради логов", держите короткий чеклист и обновляйте его по мере работ:

• точка мониторинга: где подключены TAP/SPAN, какие VLAN/сегменты видим, что точно не попадает в зеркалирование
• базовая линия: объем трафика по времени суток, типичные приложения, пики, критичные направления
• логи и хранение: какие логи включены, срок хранения, кто имеет доступ, как помечаются события пилота
• отчетность: формат ежедневной сводки и итогового отчета, дедлайны, критерии "пилот успешен/неуспешен"
• ответственные: владелец сервиса, сеть, ИБ, администратор NGFW, дежурная смена и канал эскалации

Дальше соберите итоговый пакет материалов, чтобы решение о переходе в инлайн принималось без догадок:

• "кто с кем говорит": направления, порты и объемы, что критично по задержкам
• топ приложений по App-ID: что реально работает, что маскируется, где есть неизвестные приложения
• кандидаты в правила: что можно разрешить явно, где нужны исключения
• риски и исключения: сервисы без шифрования, нестандартные порты, устаревшие клиенты, зависимость от DNS/NTP
• план логирования после включения: что продолжать собирать и кто смотрит первые 72 часа

Мягкое включение лучше планировать этапами: сначала режим allow-only с логированием (без блокировок), затем точечные запреты на явно вредоносное и запрещенное, потом ужесточение по зонам и приложениям. Для каждого этапа заранее договоритесь, как выглядит откат: кто принимает решение и сколько времени это занимает.

Интегратора стоит подключать, когда нужно проектирование инлайн-схемы (маршрутизация, L2/L3), отказоустойчивость (HA, питание, каналы), а также настройка процессов и обучение дежурных. Если пилот проходит в живой сети с критичными сервисами, особенно важно заранее отработать действия при инцидентах.

Если вам нужно пройти весь путь от пилота до безопасного инлайна (включая схему включения, HA и регламенты дежурной поддержки), это удобно делать вместе с командой GSE.kz (gse.kz) как системным интегратором, чтобы итоговые артефакты пилота сразу легли в рабочий план переключения и сопровождения.