Palo Alto Networks. Учимся думать, как firewall. Сессии и состояния

Настоящей статьей начинаем цикл статей, посвященных траблшутингу (решению проблем) и анализу работы межсетевых экранов производства Palo Alto Networks одного из мировых лидеров в сфере разработки оборудования для обеспечения информационной безопасности. В основе статьи лежит многолетний опыт работы с продуктами вендора экспертов сервис-провайдера Angara Professional Assistance, который обладает статусом авторизованного сервисного центра (ASC) Palo Alto Networks.

Что такое сессия?

Для начала давайте разберемся, что такое сессия, и как она работает в разрезе межсетевого экрана Palo Alto Networks.

Каждая сессия это набор из двух ключей потока (Client-to-Server и Server-to-Client). Каждый ключ потока это хэш следующих параметров:

1. IP protocol identifier (TCP, UDP, ICMP) (протокол);

2. Source IP address (IP-адрес источника);

3. Destination IP address(IP-адрес назначения);

4. Source port number (порт источника);

5. Destination port number(порт назначения);

6. Ingress zone ID (уникальный ID для каждой входящей зоны на межсетевом экране).

У Palo Alto Networks можно встретить термин 6-tuple. Это уникальный идентификатор, полученный из перечисленных выше шести параметров.

Для каждого полученного пакета межсетевой экран хэширует данные 6-tuple, чтобы получить соответствующий ключ потока. После чего межсетевой экран сверяет ключ потока для каждого нового пакета, чтобы сопоставить его с нужной сессией.

На данном рисунке приведен пример частичного вывода команды >show session id 52975, где мы можем видеть каждый из 6 параметров ключа потока. Стоит отметить, что хэшируются 6-tuple только у входящих пакетов. То есть это всегда будет именно ingress-зона.

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

С этим разобрались, поехали дальше. Давайте теперь разберем вывод команды >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, это еще не значит, что далее весь трафик для этой сессии будет разрешен. После того как межсетевой экран создаст сессию, к ней будут применены механизмы App-ID, Content Inspection, вследствие которых сессия может быть отброшена после инспекции полезной нагрузки какого-нибудь пакета.

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

Похожую информацию мы можем получить, используя CLI и команду >show session all. Данную команду также можно использовать с различными фильтрами.

Далее мы можем перейти внутрь каждой сессии для получения более расширенной информации, используя команду >show session id <session number>.

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.

Информацию, аналогичную разделу Monitor > Traffic, можно посмотреть и через CLI. Делается это командой >show traffic log direction equal backward. Под direction equal backward подразумевается, что вы будете просматривать логи с конца.

Cli лайфхаки

Напоследок упомянем пару лайфхаков и фишек использования CLI.

Вот основной список команд, разбитых на разные категории:

• Network:

  • Ssh подключение к другим хостам;

  • Scp, tftp, ftp загрузка и выгрузка файлов;

• Monitoring / Troubleshooting:

  • Ping, traceroute базовый траблшутинг;

  • Debug многоцелевая команда (ее мы будем использовать в будущих статьях);

  • Tcpdump для захвата пакетов с management plane межсетевого экрана;

  • Test для проверки работы различного функционала;

• Display:

  • Show для вывода конфигураций, логов и различных системных данных;

  • Tail аналог одноименной команды в юниксе, показывает последние данные из файла;

  • Less, grep также одноименные команды, знакомые многим; позволяют гибко искать информацию в лог-файлах;

• System:

  • Request для использования системных команд типа shutdown;

  • Clear используется для удаления и очистки различных параметров;

• CLI navigation:

  • Configure вход в режим редактирования конфигурации;

  • Exit выход из режима редактирования конфигурации.

Конечно же есть и другие команды, коих огромное количество. Запомнить их сразу будет крайне сложно. Тут нам на помощь приходит замечательная команда find.

Синтаксис выглядит следующим образом: >find command keyword <keyword>

Предположим, вам нужно посмотреть какую-то информацию относительно маршрутизации OSPF, но вы забыли, с помощью какой команды это делается. Вводим >find command keyword ospf.

Мы получим приблизительно такой список (полный список на скриншоте не уместится), где будут приведены примеры всех команд, в которых есть слово OSPF.

Или мы хотим перезагрузить межсетевой экран, но забыли, как это делать. Пробуем >find command keyword restart.

В полученном списке можно найти нужную нам команду: >request restart system.

Заключение

В этой части цикла статей мы разобрали, что такое сессия с точки зрения межсетевого экрана, рассмотрели различные ее настройки и способы просмотра информации о сессиях.

В следующей статье мы постараемся разобраться, как и в какой последовательности сессии и потоки (packet flow) обрабатываются движками межсетевого экрана, а также рассмотрим логику всего этого процесса.