Network, Security: PaloAlto

• АХАХАХХА в ролике о PA performance тестах рандомный чел “I bet it’s full of backdoors for the NSA.“
• checkpoint vs paloalto – software based/hatdware based; both degrades on SMB
• 
• Агрегация знаний Батранкова
• PaloAlto используют iptables, возможно им закрывают mgmt интерфейс

А кто нибудь в курсе, для чего именно они это используют? Судя по картинке их архитектуры, у них весь пайплайн в собственном приложении на dpdk, в частности, роутинг и фаервол. При чем тут iproute и iptables  - не очень понимаю. Разве что для мнг интерфейса.

• Пример почему нужны правила по пользователям/группам, файлам, приложениям и действиям пользователя в приложении

• Пример user identity с использованием разных интеграций
  • самая популярная AD – 95%; почему то интеграция через WMI считается не очень хорошей
  • exchange
  • terminal
  • XML API
  • Captive portal
  • PA VPN client
  • Client probing
  • Port mapping (terminal services agent)
  • Syslog listening

• Пример cloud sandbox, включая проверку файлов на bare metal серверах (защита от незапуска в виртуальной среде)

• Пример application visibility статистики (DPI).

• Даже PaloAlto, несмотря на детект по умолчанию приложений по всем портам, в правилах имеют возможность задания разрешения приложениям работы только на своем well-known порту – `application-default. Это безопаснее и может быть быстрее (конкретно для их реализации с одним Single Pass Engine вероятно нет, но легко сделать так, когда это будет работать быстрее).

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/app-id/application-default
Stronger security — Enabling applications to run only on their default ports is a security best practice. Application-default helps you to make sure that critical applications are available without compromising security if an application is behaving in an unexpected way.

• Поддерживаются различные схемы деплоя (как и с FTD), хотя самая популярная и функциональная – L3.

• У Palo Alto Networks многое делают аппаратные чипы FPGA, которые работают в устройстве параллельно одновременно с потоком трафика, а у Cisco нет параллельной работы чипов для разных функций безопасности.Подробнее: https://www.securitylab.ru/blog/personal/Morning/346127.php
• management plane PA – отдельный комп (проц, cpu, memory, nic)

• Paloalto реализовала
  • в рамках единого контекста/модуля/кода все операции ngfw (Single Pass Engine – SPE) – dpi, urlf, ips, antivirus, routing/switching, vpn с определением пользователей (общая инфа о пользователях и приложениях для всех функций);

• • при этом так же используют и ускорения FPGA – signature ips/antivirus matching с использованием FPGA,
  • cavium процессоры с большим количеством ядер (48 ядер в palo alto 52xx) – используются для задач DPI, URLF, ssl/tls inspection, archive decompression, для обработки того, что не ускоряется на FPGA. Offtop (дублируется в PaloAlto и Usergate) при этом у Intel потенциально есть многоядерные процессоры, которые способны решать задачи, которые закрываются специализированными процессорами Cavium (PaloAlto, Ixia, etc):
    • Cisco использовала Cavium в Catalyst 3850, но x86 в Catalyst 9×00
    • Вендоры NGFW используют так же Intel Xeon Phi 7290 c 72 ядрами и Xeon Platinum 8176 c 28 ядрами

• PA активно используют ML (Machine Learning) в своих устройствах
  • создание сигнатур на основе ML
  • рекомендации правил безопасности на основе ML
• Поддерживают HTTP/2, TLS 1.3
• Есть отдельный продукт NGFW для Kubernetes (k8s)

Нагрузочные и security effectiveness тестирования PA (Jerish Parapurath, Денис Батранков):

Summary:

• Политики безопасности должны отражать продакшн среду (one size does not fit all, use custom(er) policy)
• Трафик должен отражать продакшн среду
• Глупо тестировать только (вообще, считаю) RFC 2544 NGFW
• Устройство должно распознавать все приложения на всех портах
• Устройство должно искать угрозы на всех портах
• Должно быть включено логгирование на правилах безопасности
• Тестируют BreakingPoint – подробности в статье

• Для тестов PA так же используют IXIA
• Для NGFW PA по умолчанию публикуют только производительность с включенным DPI, т.е. не в режиме «обычного межсетевого экрана», при этом у PA NGFW есть режим работы K2 express, который реализует «обычный межсетевой экран» – кейс для мобильных сетей (думаю так же и для DC/ISP).

• Даже тестирования PA (даже потому что PA во многом эталон) внутри компании не соответствуют netsecopen в сторону упрощения тестирований:

• • ниже про SSL inspection, который тестируют с 50% session resumption
  • CPS тестировали с 1 байт страницей (в datasheet открыто пишут)

• В тестах NSS PA блокировал все 1800 эксплойтов (кроме одного) и блокировал все!!! 406 техник обхода NGFW. ((Cisco по evasion не сильно отставал по другим evasion тестам))
• в видео так же троллинг конкурентов – что есть вендоры, которые автоматически отключают функции безопасности при высокой нагрузке сами или руками админов, превращаясь в роутер по цене NGFW ((пример привел теста PfSense и пропуска ей атак под нагрузкой; но мы то знаем такое поведение возможно и для snort Firepower – см. fail open сценарии, напр. Rule handling thresholds)).
• CPS и TPS
  • Скорость в виде cps крайне важна для NGFW, но про нее часто забывают.
  • В NGFW при этом самое важное измерять транзакции в секунду tps, не пакеты или даже коннекции. Потому что пакеты – это про роутеры, а коннекции не подразумевают независимые транзакции внутри одной коннекции (http 1.1, 2/3). PA пишут что используют 1 TPS (HTTP Get) в одной коннекции (выше).
• Про CC в целом верно сказал про connection tracker – одно дело запоминать сессию udp, другое tcp, SSL и тем более application со всеми нужными атрибутами, но при этом специфичные application атрибуты по факту нужны далеко не всегда, а только если мы реализуем сложный анализ приложения, например почтового письма (subject, body, from, to, signature, etc), а не просто блокируем или разрешаем
• Про THPT ок (разные уровни OSI – разное значение производительности, суммарный объем трафика интерфейсов в datasheet, а не одно направление), но, оказывается
  • THPT в байтах в секунду измеряется 😀
  • есть такая сущность как пакет в 64000 байт (64Кбайт) 😃
• Есть отдельна метрика в datasheet – throughput при включенном DSRI (disalbe server response inspection). Для сценария защиты доверенных серверов может быть реальный индикатор/полезная фича.
• Некоторые вендоры при тестировании DPI определяли приложения, но не могли их блокировать
• Вендоры зачастую при тесте TLS/SSL inspection отключают весь остальной функционал анализа трафика

• Производительность SSL inspection & decryption сильно зависит от размера транзакций, количество транзакций в соединении, алгоритма шифрования, размера ключей, переиспользования ключей
  • (некорректно с точки зрения netsecopen) PA использовали TLS session resumption в 50% при своих тестированиях (обосновывают тем, что у клиентов в реальной сети сходный resumption rate)
  • Используемые шифры очень похожи на те, что выбраны by default в текущей версии netsecopen draft
  • При тестировании часть трафика у кого-то может не расшифровываться по факту, “мы в PA” проверяем, что он весь расшифровался – как понимаю в статистике под WEB трафик заматчился весь трафик (или еще проще реализация – ACL по умолчанию пропускает только WEB).

1. ECDHE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash
Algorithm: ecdsa_secp256r1_sha256 and Supported group: secp256r1)
2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash
Algorithm: rsa_pkcs1_sha256 and Supported group: secp256r1)
3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp521 (Signature Hash
Algorithm: ecdsa_secp384r1_sha384 and Supported group: secp521r1)
4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash
Algorithm: rsa_pkcs1_sha384 and Supported group: secp256r1)