palo alto firewall что это
Межсетевые экраны Palo Alto Networks VM-Series
Компания Palo Alto Networks была основана в 2005 году Ниром Зуком (Nir Zuk) и группой старших инженеров компаний, лидирующих в сфере сетевой безопасности – Check Point, Cisco, NetScreen, McAfee, Juniper Networks, и занимается разработкой брандмауэров нового поколения, позволяющих контролировать работу приложений и пользователей в корпоративных сетях. Целевой аудиторией компании являются крупные организации, занятые в сфере образования и здравоохранения, а также компании финансового сектора.
Главная идея этого межсетевого экрана состоит в том, что политики безопасности применяются не к портам или IP-адресам, а к конкретным пользователям служб каталогов и приложениям. Более того, он предоставляет огромные возможности по мониторингу трафика приложений, действий пользователей и передаваемого содержимого за счет использования уникальных технологий идентификации.
Для идентификации используемых приложений специалисты Palo Alto Networks разработали уникальную технологию классификации трафика, получившую название App-ID. Она не зависит от портов, протоколов, методов маскирования или шифрования и базируется на нескольких принципах обнаружения: идентификация протокола обмена данными и его расшифровка, классификация передаваемых данных, использование контекстных сигнатур для сканирования трафика приложений, эвристический анализ неизвестных данных.
Используя весь комплекс методов, оборудование Palo Alto Networks безошибочно вычленяет неизвестные приложения и, более того, позволяет отслеживать различные сценарии их применения. Что касается корпоративных приложений, то пользователь может вручную установить классификаторы и работать с ними.
Брандмауэры Palo Alto Networks предлагают еще одну технологию – User-ID, которая нужна для идентификации пользователей в подконтрольных сетях. Она поддерживает интеграцию с популярными пользовательскими репозиториями (Microsoft Exchange Server, Novell eDirectory, Microsoft AD) и серверами удаленного доступа (Citrix XenApp, Microsoft Terminal Services), а также XML API для интеграции со сторонними пользовательскими репозиториями (прокси, беспроводное оборудование и т.д.).
Даже через разрешенные приложения авторизированный пользователь может получить доступ к небезопасному контенту или случайно открыть доступ к конфиденциальной информации. По этой причине было решено, что брандмауэр должен анализировать передаваемый контент, и все методики, позволяющие работать с контентом, объединены в одну технологию – Content-ID. На сегодняшний день она включает в себя полнофункциональный IPS, URL-фильтрацию, подсистему DLP, сетевой антивирус и AntiSpyware.
Все вышеперечисленные функции воплощены во всех линейках продуктов компании Palo Alto Networks:
Palo Alto Networks серии VM работает под управлением операционной системы PAN-OS, которая руководит аппаратными и программными составляющими брандмауэров Palo Alto Networks. Она поддерживает огромное количество функций и сервисов, обеспечивающих гарантированно надежную и защищенную среду. Также в PAN-OS разнесены логики управления и обработки трафика, что позволяет сохранить управляемость межсетевым экраном даже в случае резкого скачка трафика.
Если же нужно управлять множеством устройств Palo Alto Networks, то можно воспользоваться специализированной платформой управления Palo Alto Networks Panorama. Panorama является надежным инструментом централизованного управления и позволяет выполнять мониторинг сетевой активности.
С помощью Panorama можно управлять распределенной сетью физических и/или виртуальных межсетевых экранов Palo Alto Networks централизованно, при этом отслеживая трафик по каждому развернутому брандмауэру и управляя конфигурациями и политиками безопасности.
Еще одним инструментом, стоящим внимания, является VMware NSX – это платформа виртуализации сети для виртуального дата-центра, которая отвечает за создание сетей на существующем сетевом оборудовании. NSX позволяет вам сформировать гибкий пул сетевых ресурсов, разворачивать полностью независимые программные сети и применять принципы виртуализации к сетевой инфраструктуре.
Важной составляющей VMware NSX являются компоненты VMware NSX Service Composer и VMware NSX Distributed Firewall (DFW). VMware NSX DFW является распределенным брандмауэром, реализованным в контексте самого NSX. Он обеспечивает возможности stateful-фильтрации и работает на уровне ядра гипервизора, что обеспечивает высокую производительность.
Управление брандмауэром осуществляется через пользовательский интерфейс vCenter. Правила, создаваемые в DFW, могут быть заданы на уровне VM, кластера, порт-группы DVS, логического свитча и так далее. NSX DFW поддерживает vMotion, а текущие активные соединения остаются нетронутыми в момент рабочей нагрузки.
Встроенный компонент VMware NSX Service Composer определяет новую модель использования сетей и сервисов безопасности. Он позволяет создавать многоуровневые политики безопасности, независимые от текущей инфраструктуры и заданной топологии.
Политики безопасности назначаются на группы виртуальных машин и автоматически применяются к новым VM, добавленным в группу. Получается, что в Service Composer вы можете создавать группы безопасности (Security Group) и политики безопасности (Policy Group).
При создании групп безопасности администратор может выбирать между статическими и динамическими группами, которые включают или исключают такие объекты, как виртуальные машины, vNIC, vSphere-кластеры, логические свитчи и прочее.
Что касается Security Policy (SP), то они определяют сетевые политики и политики безопасности, применяемые для конкретной группы безопасности. Например, SP может быть создана для перенаправления на Palo Alto Networks VM-Series любого типа трафика. Чтобы политика безопасности заработала, ее необходимо привязать к группе или набору групп безопасности.
В одной из статей нашего блога мы рассмотрели практический пример, связанный с конфигурацией динамических политик безопасности и устранением обнаруженных ошибок.
В вымышленной организации были развернуты три виртуальные машины HR-отдела, две из которых выступали в роли веб-сервера, а одна – в качестве сервера базы данных. Каждая из виртуальных машин подключалась к одному и тому же логическому свитчу (VXLAN).
Защита трафика обеспечивалась следующим образом: трафик от веб-сервера до сервера базы данных «прикрывался» брандмауэром Palo Alto Networks серии VM, а трафик от веб-сервера к веб-серверу – NSX DFW.
Подробное руководство с разбором всех возникающих проблем вы можете просмотреть здесь.
Palo Alto Networks. Учимся думать как firewall. Сессии и состояния
Настоящей статьей начинаем цикл статей, посвященных траблшутингу (решению проблем) и анализу работы межсетевых экранов производства Palo Alto Networks – одного из мировых лидеров в сфере разработки оборудования для обеспечения информационной безопасности. В основе статьи лежит многолетний опыт работы с продуктами вендора экспертов сервис-провайдера Angara Professional Assistance, который обладает статусом авторизованного сервисного центра (ASC) Palo Alto Networks.
Что такое сессия?
Для начала давайте разберемся, – что такое сессия, и как она работает в разрезе межсетевого экрана Palo Alto Networks.
Каждая сессия – это набор из двух «ключей потока» (Client-to-Server и Server-to-Client). Каждый «ключ потока» – это хэш следующих параметров:
IP protocol identifier (TCP, UDP, ICMP) (протокол);
Source IP address (IP-адрес источника);
Destination IP address(IP-адрес назначения);
Source port number (порт источника);
Destination port number(порт назначения);
Ingress zone ID (уникальный ID для каждой входящей зоны на межсетевом экране).
У Palo Alto Networks можно встретить термин «6-tuple». Это уникальный идентификатор, полученный из перечисленных выше шести параметров.
Для каждого полученного пакета межсетевой экран хэширует данные 6-tuple, чтобы получить соответствующий «ключ потока». После чего межсетевой экран сверяет «ключ потока» для каждого нового пакета, чтобы сопоставить его с нужной сессией.
Итак, получается, что сессия – это связанный «ключом потока» набор однонаправленных потоков данных между клиентов и сервером.
С этим разобрались, поехали дальше. Давайте теперь разберем вывод команды >show session info :
В первой части вывода данной команды мы можем видеть общее доступное число одновременных сессий для текущей платформы, на сколько процентов использована таблица сессий, количество пакетов в секунду, пропускную способность (за исключением аппаратно-разгруженных пакетов (offloaded traffic)), а также информацию о новых соединениях в секунду (CPS).
Далее мы можем видеть различные настройки таймаутов, которые, при желании, можно менять.
Далее идет информация о том, насколько быстро наступит таймаут у сессий при достижении определенного порога утилизации таблицы сессий. На примере скриншота: если таблица сессий будет использована более, чем на 80%, то таймаут у TCP-сессий будет не 3600 секунд, а 1800. Если Scaling factor будет равен 10, то, соответственно, таймаут у сессий будет равен 360 секундам.
Далее идет информация о различных параметрах, которые влияют на установку новых сессий. Например, будет ли использоваться проверка TCP SYN, включена ли аппаратная разгрузка сессий.
В конце приводится информация о «хитрой» опции «Application trickling», которая означает, что если мы превышаем лимит по ресурсам межсетевого экрана (например, пакетного буфера), то запускается механизм сканирования сессий. Если сессия была неактивна более, чем trickling-лимит, то буфер, который был задействован данной сессией, очистится. То есть, по сути, это механизм для дополнительной защиты ресурсов межсетевого экрана.
Состояния сессий
Каждая сессия в любой момент времени находится в одном из шести состояний. Зеленым обозначены состояния, которые мы можем наблюдать в веб-интерфейсе или командной строке (CLI) межсетевого экрана.
INIT: каждая сессия начинается с состояния инициализации (INIT). Сессия в состоянии INIT является частью пула свободных сессий.
ACTIVE: любая сессия, которая соответствует потоку трафика, который еще не истек по таймауту, и который активно используется для проверки (например, механизмом App-ID) или для отправки по адресу назначения (destination forwarding).
DISCARD: трафик, ассоциированный с сессией, которая была заблокирована на основании политик безопасности или в результате обнаружения угрозы. Пакет, на который сработала политика или детектор угроз, был отброшен; все последующие пакеты, принадлежащие к сессии в состоянии DISCARD, будут отброшены без всякой проверки.
Остальные состояния сессии (OPENING, CLOSED, FREE) являются транзитными. Транзитные состояния можно увидеть достаточно редко, так как в данных состояниях сессия надолго не задерживается.
В нормальных условиях каждая сессия пройдет полный цикл, начиная с состояния INIT и заканчивая FREE.
Просмотр информации о сессиях
Посмотреть информацию о сессиях в реальном времени можно как через веб-интерфейс, так и через CLI межсетевого экрана. Session Browser может быть полезным инструментом для траблшутинга без необходимости захвата пакетов или использования debug-логов. Мы можем посмотреть, создает ли ожидаемый трафик соответствующую сессию, как она категорируется механизмом App-ID, и каким образом и из-за чего эта сессия завершается.
Session Browser» title=»Monitor > Session Browser» height=»282″ data-src=»https://habrastorage.org/getpro/habr/upload_files/059/56b/5cc/05956b5cc8d61bda468c3d7df59c56af.png» data-width=»1204″/> Monitor > Session Browser
Если вы видите сессию в Session Browser, это еще не значит, что далее весь трафик для этой сессии будет разрешен. После того как межсетевой экран создаст сессию, к ней будут применены механизмы App-ID, Content Inspection, вследствие которых сессия может быть отброшена после инспекции полезной нагрузки какого-нибудь пакета.
В данном меню можно применять различные фильтры, например, отфильтровать сессии по названиям правил безопасности, через которые они проходит. Так же мы можем принудительно завершить сессию, нажав на крестик.
c2s flow – поток от клиента к серверу. Инициатор потока.
s2c flow – поток от сервера к клиенту. Ответный поток.
Детальную информацию о сессии можно также посмотреть через меню Monitor > Traffic > Detailed Log View. По сути, там будет та же информация, которую вы получите через CLI.
Посмотрите, как межсетевой экран переопределяет приложение в рамках одной сессии. Сначала движок определил тип URL, риск, категорию, проверил не блокируется ли сессия согласно политикам URL-filtering. Далее межсетевой экран по первым пакетам определил приложение web-browsing и проверил, разрешено ли оно политиками безопасности. Как только стало приходить больше пакетов с полезной нагрузкой, согласно встроенной (и постоянно обновляемой) базе сигнатур, межсетевой экран увидел приложение google-base, после чего в очередной раз проверил, разрешено ли оно политиками.
Данный механизм очень полезен при траблшутинге и называется «application shifting». Более подробно мы его затронем в следующей статье.
Также очень важно понимать причину, по которой завершилась сессия. Это сильно упрощает процесс траблшутинга. Список возможных причин.
«threat» – была обнаружена угроза, и политиками безопасности было применено действие «reset», «drop» или «block».
«Policy-deny» – к сессии была применена политика безопасности с действием «deny» или «drop».
«Decrypt-cert-validation» – в большинстве случаев означает, что сессия была заблокирована потому, что для ssl-инспекции была настроена проверка сертификатов, которая не была пройдена. Сертификат мог быть просрочен или выдан недоверенным источником, или не смог пройти верификации по таймауту и т.д.
«decrypt-error» – сессия была заблокирована из-за того, что при настроенной ssl-инспекции межсетевому экрану не удалось расшифровать сессию из-за нехватки ресурсов. Также эта ошибка появляется, когда возникают проблемы с протоколом SSH или любые другие ошибки SSL, помимо тех, которые описаны в пункте «decrypt-unsupport-param».
«tcp-rst-from-client» – клиент отправил tcp-rst в сторону сервера.
«tcp-rst-from-server» – сервер отправил tcp-rst в сторону клиента.
«resources-unavailable» – сессия была заблокирована из-за ограничения ресурсов межсетевого экрана. Например, в сессии могло быть превышено количество пакетов с нарушением порядка (out-of-order), разрешенных для одной сессии.
«tcp-fin» – оба хоста отправили tcp-fin для завершения сессии.
«tcp-reuse» – сессия используется повторно, и межсетевой экран закрыл предыдущую сессию.
«Decoder» – декодер обнаружил новое соединение в рамках протокола и завершает предыдущее соединение.
«Unknown» – применяется в следующих ситуациях:
Сессия завершилась из-за причин, не указанных до этого. Например, кто-то завершил сессию вручную командой >clear session all.
Устаревшая версия PAN-OS (ниже 6.1), в которой не поддерживается функционал определения причин завершения сессий.
«n/a» – статус, который присваивается, когда сессия еще не была завершена, то есть, когда тип лога не в значении «end».
Cli лайфхаки
Напоследок упомянем пару лайфхаков и «фишек» использования CLI.
Вот основной список команд, разбитых на разные категории:
Ssh – подключение к другим хостам;
Scp, tftp, ftp – загрузка и выгрузка файлов;
Ping, traceroute – базовый траблшутинг;
Debug – многоцелевая команда (ее мы будем использовать в будущих статьях);
Tcpdump – для захвата пакетов с management plane межсетевого экрана;
Test – для проверки работы различного функционала;
Show – для вывода конфигураций, логов и различных системных данных;
Tail – аналог одноименной команды в юниксе, показывает последние данные из файла;
Less, grep – также одноименные команды, знакомые многим; позволяют гибко искать информацию в лог-файлах;
Request – для использования системных команд типа «shutdown»;
Clear – используется для удаления и очистки различных параметров;
Configure – вход в режим редактирования конфигурации;
Exit – выход из режима редактирования конфигурации.
Конечно же есть и другие команды, коих огромное количество. Запомнить их сразу будет крайне сложно. Тут нам на помощь приходит замечательная команда «find».
Синтаксис выглядит следующим образом: >find command keyword
Мы получим приблизительно такой список (полный список на скриншоте не уместится), где будут приведены примеры всех команд, в которых есть слово «OSPF».
Заключение
В этой части цикла статей мы разобрали, что такое сессия с точки зрения межсетевого экрана, рассмотрели различные ее настройки и способы просмотра информации о сессиях.
В следующей статье мы постараемся разобраться, как и в какой последовательности сессии и потоки (packet flow) обрабатываются движками межсетевого экрана, а также рассмотрим логику всего этого процесса.
Palo Alto Networks Panorama. Основы настройки и управления
Привет дорогие читатели! Сегодня мы кратко расскажем о таком продукте, как Panorama от компании Palo Alto Networks. По какой-то причине на русском языке достаточно мало информации о настройке и основных принципах работы. Что ж, давайте будем заполнять эти пробелы.
Panorama – это система централизованного мониторинга и управления межсетевыми экранами нового поколения (NGFW) Palo Alto Networks, которые в последнее время все больше и больше набирают популярность. В том числе мы в компании Angara Professional Assistance работаем с этим продуктом достаточно часто. В 2019 году аналитическое агентство Gartner 8 раз признало их лидерами в своем Magic Quadrant. С помощью Panorama мы можем агрегировать и хранить логи со всех межсетевых экранов, строить отчеты, управлять настройками (используя гибкое разграничение доступов), лицензиями, обновлениями и даже следить за состоянием аппаратного обеспечения.
Но давайте по порядку.
Panorama поставляется в качестве ПАК или виртуального апплайнса. Виртуальный апплайнс имеет такой же функционал, как у ПАК. Виртуальный апплайнс можно развернуть на VMware ESXi, Google Cloud Platform, Amazon Web Services, Microsoft Azure. Лицензирование на всех платформах одинаковое. Panorama поддерживает работу в кластере.
Panorama может работать в трех режимах (на самом деле, в четырех, но последний сильно устарел и не рекомендован к новым установкам):
Давайте рассмотрим наиболее популярную архитектуру и режим работы Panorama Mode. Данный режим используется по умолчанию, поэтому дополнительных действий по его активации не требуется.
После регистрации устройства на Support Portal подключаемся к Panorama через MGT-интерфейс на IP 192.168.1.252, admin/admin. Если мы используем виртуальный апплайнс, то необходимо задать первоначальные настройки через командную строку:
Начальный интерфейс очень схож с тем, который вы увидите на межсетевом экране.
Полный интерфейс будет доступен после конфигурации разделов Template и Device Group, но об этом немного позже.
Лицензирование
Подготовка
Начальная конфигурация устройства несильно отличается от той, что вы выполните на межсетевом экране. В разделе Panorama > Setup > Management Services прописываем DNS- и NTP-серверы (если мы не сделали это вначале через CLI).
Настройки применяются так же – через меню Commit, которое здесь разделено на три части: Commit to Panorama, Push to Devices, Commit and Push.
Добавление межсетевых экранов в Panorama
Итак, давайте перейдем к функционалу, ради которого это решение и создавалось, а именно, к добавлению межсетевых экранов для последующего управления.
Происходит это в три шага:
Применяем все настройки на межсетевом экране и Panorama.
После чего в этом же меню Panorama > Managed Devices > Summary мы увидим, что статус устройства стал «Connected», а также появилась информация по серийному номеру, IP-адресу, модели, версии баз сигнатур и прочая информация.
Существуют нюансы, когда Вам, например, необходимо добавить уже давно используемый межсетевой экран, перенеся все существующие политики и настройки под управление Panorama. Или когда Вам надо перенести сотни межсетевых экранов и автоматизировать данный процесс. Затрагивать каждый нюанс на данном этапе мы не будем, можно лишь сказать, что процесс – совсем нетрудный.
Templates
Templates и Device Groups это две ключевые настройки, которые поначалу вызывают наибольшие трудности понимания у тех, кто сталкивается с Panorama.
Templates – это объекты, создаваемые на Panorama, в которых хранятся данные, относящиеся к разделам Network и Device на межсетевых экранах.
Template’ов может быть несколько, поэтому, внося изменения в разделы Network и Device на Panorama, необходимо выбирать соответствующий Template.
Меню выбора Template’ов
Template Stacks – набор, который может быть сформирован из восьми Templates. Иерархически это выглядит как 8 слоев. Настройки на верхнем слое распространяются на нижний и имеют больший приоритет. Создаются они в том же разделе, где и обычные Templates.
Templates Variables
Предположим, что у нас много межсетевых экранов, которые управляются с помощью Panorama и имеют внутренние IP-адреса от 10.0.1.1/24 до 10.0.100.1/24. Чтобы не создавать 100 разных Template’ов для каждого из них, можно воспользоваться функционалом переменных значений.
Давайте разберемся, как это сделать, на примере ситуации выше.
Перейдем в меню Panorama > Templates и создадим Template, который будет отвечать за IP-адреса на интерфейсах межсетевых экранов. Назовем его “Firewall interfaces”. Перейдем в меню Network > Interfaces и, убедившись, что сверху выбран созданный нами Template, перейдем в настройки нужного нам интерфейса, например, ethernet1/1. Перейдя в раздел IPv4, нажмем кнопку Add, чтобы добавить значение IP-адреса, после чего нажмем на New X Variable. Здесь можно создать новую переменную. Дадим ей имя и значение.
Данные действия позволили нам с помощью Panorama в рамках одного Template ввести разные значения для нескольких межсетевых экранов. Мы можем пойти и по менее удобному пути, используя функционал Override непосредственно на межсетевых экранах. Если администратор разрешил перезаписывать значения, которые поступают с Panorama, то можно, используя данный функционал локально на межсетевом экране, и перезаписать значение, переданное с Panorama (в данном случае IP-адрес).
В конце концов мы можем вообще не определять IP-адреса интерфейсов на Panorama, а сделать это локально на каждом МСЭ.
Device Groups
Теперь давайте поговорим о схожей концепции – Device Groups.
Device Groups – это объекты, создаваемые на Panorama, в которых хранятся данные, относящиеся к разделам Policies и Objects на межсетевых экранах.
Как и Templates, Device Groups закрепляются за определенными межсетевыми экранами. Межсетевой экран также может принадлежать к иерархии групп. Принцип немного отличается от Templates.
Пример иерархии групп
Стоит заметить, что после того как мы создадим первую группу, у нас появится общая группа с названием Shared, настройки которой будут распространяться на все остальные группы.
Что будет, если закрепить за устройством Device Group, но не закреплять Template?
Мы можем столкнуться с трудностями, например, при создании новой политики безопасности (Security Policy): в разделе выбора зон у нас не будет доступно ничего, кроме Any. Это объясняется тем, что за устройством не закреплено ни одного Template, в котором эти зоны были бы обозначены. Один из способов решения данной проблемы – это Reference Templates. Когда вы создаете Device Group и добавляете в нее устройство, у вас так же есть возможность указать ссылку на шаблон.
Reference Templates
Мы можем создать Template, в котором будут обозначены зоны, после чего просто сделать на него ссылку из меню создания или редактирования Device Group.
Policies
Как мы уже знаем, Device Groups также управляет политиками, которые отправляются на межсетевой экран с Panorama. В отличие от обычного редактора политик, здесь у нас появились новые разделы: Pre Rules, Post Rules, Default Rules.
С точки зрения иерархии, все это работает следующим образом (не стоит забывать, что, помимо обычных Device Group, у нас также есть общая группа Shared):
На первый взгляд это может немного пугать, но, на самом деле, все куда проще. Иерархия политик будет понятна после первых нескольких созданных правил. К тому же, вы всегда можете посмотреть, как итоговые правила будут выглядеть на конечном устройстве. Для этого можно воспользоваться кнопкой Preview Rules в разделе редактирования политик.
Когда вы создаете правило, также имеется возможность выбрать цель (Target) для закрепления политики за определенным устройством. На практике данный функционал автор статьи считает не самым удобным, потому что он может привести к путанице с политиками на разных устройствах при их общем отображении в одном окне. Однако все зависит от человека. Возможно, кому-то это покажется удобным.
Выбор устройств, на которые будут распространяться политики
Есть еще очень интересный функционал для тех, кто любит порядок. В настройках Panorama можно задать необходимые поля, которые нужно заполнять, создавая правила, в противном случае произойдет «Commit fail». Это удобно и, например, приучает администраторов всегда добавлять описания к создаваемым ими правилам или вешать тэги. По описанию мы сможем понять, какой замысел был у того или иного правила, по тэгам мы можем сгруппировать правила, отфильтровав ненужные.
Логирование
Теперь давайте пройдемся по логам.
Panorama получает информацию о логах из двух источников: локального и удаленного.
Локальный источник – логи, которые были направлены самим межсетевым экраном на Panorama. Логи, которые Panorama запросила и получила от Log Collector’ов и Cortex Data lake (их мы не будем затрагивать в данной статье).
Удаленный источник – логи, которые запрашиваются у межсетевого экрана.
Также существуют два типа логов: Summary Database и Detailed Logs.
Поиск проблем
Теперь давайте на верхнем уровне рассмотрим вопросы отладки.
Стоит почаще проверять раздел Device Summary. Там можно найти информацию о состоянии устройств, подключенных к Panorama. Например, мы можем увидеть следующую ситуацию:
В данном случае мы видим, что конфигурация межсетевого экрана рассинхронизировалась с Panorama из-за того, что произошла ошибка «commit failed». Информацию о причинах данной ошибки можно посмотреть, кликнув на красную ссылку commit failed.
В меню Panorama > Managed Devices > Health можно получить информацию о состоянии устройств: пропускной способности, количестве новых сессий в секунду, общем количестве сессий, загрузке процессора на Data Plane и Management Plane, использовании памяти, количестве логов в секунду, состоянии вентиляторов и блоков питания. Также всю данную информацию можно посмотреть в виде графиков.
Раз уж мы упомянули про ресурсы и отладку, в рамках данной статьи упомянем замечательный плагин для браузера Chrome под названием Pan(w)achrome. Включается он после ввода учетных данных в веб-интерфейсе межсетевого экрана. В плагине можно посмотреть общую информацию о состоянии устройства и получить не только более детальную информацию по загрузке ресурсов, чем мы увидим на Panorama, но и даже посмотреть статистику по тем или иным счетчикам (counters) (полный список не поместился в скриншот):
Конечно, данную информацию в куда более развернутом виде и с описанием счетчиков можно узнать через CLI устройства, однако, это отдельная тема для другой статьи, посвященной отладке. Данный же плагин позволит наглядно в графическом формате оценить, что происходит с тем или иным устройством. И для 70% возникающих проблем этого может быть вполне достаточно.
Что ж, вернемся обратно к «земным» проблемам. И одна из наиболее частых проблем связана с подключением Panorama к межсетевым экранам. Для этого нам необходимо проверить доступность следующих портов:
Замена устройств
Напоследок затронем не самую частую ситуацию, такую как замена межсетевых экранов, подключенных к Panorama. Опустим нюансы по переносу лицензий со старого устройства на новое (об этом вы можете почитать в официальных руководствах по запросу «how to transfer licenses to a spare device») и перейдем сразу к последовательности настройки:
После того как мы завершили трансфер, необходимо поменять серийный номер старого устройства на новый:
Заключение
Конечно же мы прошлись только по самым верхам настройки Panorama и не затронули много нюансов. Однако понимание верхов позволит подключить межсетевые экраны к Panorama, разобраться в ее основных функциях и начать более гранулированную настройку самостоятельно.
Если затронутая тема оказалась для вас интересной, в следующих статьях постараемся более детально осветить вопросы отладки (траблшутинга), которые обычно отдают на решение технической поддержке либо ASC (Authorized Support Center) и которые отсутствуют в официальных руководствах производителя, доступных рядовым клиентам.
Можем затронуть такие темы, как: