Результаты тестирования межсетевых экранов 2024 года

В тесте NGFW участвовали Континент 4.1.7, CheckPoint 81.20, UserGate 7.1.0, Sangfor 8.0. Опубликовали тест 29 февраля 2024 года.

Возникает первый вопрос: был ли реальный тест функций или по документации. Коллеги заявляют, что проверяли сами часть функционала, часть смотрели по документации.

Поэтому важно посмотреть саму методику тестирования. 

Методики тут:

• Функциональная методика
• Нагрузочная методика 

Впечатления 

• Меня удивили NAT-правила для определенных правил МСЭ в Континент. Интересно посмотреть как это на практике.
• Понравилось, что были проверки работы обнаружения приложений на нестандартных портах.
• Интересно было посмотреть особенности каждого МСЭ - что движки делают с трафиком после расшифрования SSL - кто-то инспектирует всеми модулями безопасности открытый трафик, а кто-то избирательно реализовал, где-то еще есть ICAP. Интересно, что почти все могут HTTPS и лишь немногие смотрят в другие протоколы на базе SSL. Про работу SSL инспекции у меня есть отдельный видеоролик.
• Интересно, что где-то нельзя загружать внешние сертификаты. Это выглядит прямо неудобным.
• Важно что проверили исключения для работы SSL для некоторых URL категорий.
• Мне всегда интересно какие есть режими подключения User-ID к AD и другим система аутентификации. По User-ID у меня тоже есть видеоролик.
• Очень круто, что описали какие 2FA/MFA поддерживаются.
• Интересно было узнать кто поддерживает ГОСТ, а кто AES для VPN.
• Классно что проверили функциональность ZTNA, то есть проверку соответствия требованиям клиентской рабочей станции самим агентом VPN.
• Показали кто и как интегрируется с песочницей, можно дополнить списком протоколов, которые разбираются и из которых файлы отправляются в песочницу.

Что еще бы добавить

• Для меня не хватило теста Virtual Wire, я его часто использовал, потому что в этом режиме удобно инсталлировать NGFW как IPS, или как прозрачный сенсор в сети АСУТП, где нельзя менять топологию. 
• Также интересно как меняются теги VLAN в L2.
• Получается ни у кого нет анализа трафика на SPAN?
• Также в проверках приложений было очень интересно сколько приложений поддерживается движком DPI. Таких данных не вижу - лучше в следующем тесте опубликовать.
• Важно в проверке приложений потестировать какие-то сложные: TOR, Telegram и российские: 1С, Одноклассники и др.
• Интересно, что некоторые производители не делают приложение критерием проверки, это лучше протестировать всегда.
• Про IPS хотелось узнать а как обновляются сигнатуры, как часто, насколько хорошо покрытие атак хотя бы по Strike 1 набору из IXIA.
• По правилам было интересно узнать как работает с большим количеством правил и какая просадка- как известно это проблема современных устройств. Хотя бы 10 тысяч правил добавить в методику.
• Можно добавить стоимость за защищенный гигабит для устройств мощностью 1, 2, 5, 10 Гбит/с с включенными функциями защиты.
• Интересно бы узнать максимальное по производительности устройство в линейке вендора.
• Также интересно где хранятся логи: локально или на центральном сервере. Это влияет на производительность. 
• Журналируются ли действия администраторов?
• Что происходит при рызрыве связи NGFW и системы управления?
• Также круто сравнить системы управления: встроенная в каждый Local Management или централизованная, сколько событий в секунду принимает лог коллектор в системе управления, что делать если не хватает одного лог коллектора и др.
• Управление через API -  как работает, хватает ли функционала для разных сценариев, с чем получилось интегрировать, например, с каким-то SOAR.

Заглянуть в зашифрованный мир интернета через SSL Decrypt в NGFW.

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

Посмотрите, ведь на вашем периметре 80% такого трафика. И вы не знаете что там внутри, верно? 

Другие новости в телеграм-канале Топ Кибербезопасности

Всем нужен межсетевой экран нового поколения (Next-Generation Firewall). А что это?

Всем нужен межсетевой экран нового поколения (Next-Generation Firewall). А что это?

Серия из 3 видеороликов раскрывает подробности работы межсетевых экранов нового поколения (NGFW).

Заходите за новостями в канал "Топ Кибербезопасности" https://t.me/+nAJuAfwWY2o4ZDFi

Анализ нового протокола HTTP/2 на NGFW

Мир не стоит на месте. Уже больше половины веб-сайтов в мире работают на HTTP/2. Причина - он более эффективный и серьезно ускоряет работу веб-сайта. Выглядит HTTP/2 для обычного сетевого анализатора как трафик TLS версий 1.2 или 1.3. В межсетевых экранах принято TLS расшифровывать и искать внутри вредоносные файлы, которые идут к вашим сотрудникам. Делаете ли это вы?

И оказывается, что в стандартном HTTPS, внутри которого работает старый HTTP/1.1 это просто было сделать, а вот в новом HTTP/2 это не так просто, потому что протокол стал использовать бинарные данные, вместо текстовых команд и файлы передаются в стримах. На самом деле в браузере ссылка на сайт с HTTP/2 выглядит также как и раньше как https:// но внутри самого сетевого трафика будет либо 1 либо 2 версия протокола HTTP. Какая будет работать версия контролируется новым расширением протокола TLS, которое называется ALPN. Поэтому сегодня важно, чтобы ваш NGFW поддерживал этот протокол и мог видеть в нем файлы. Проверьте это сегодня. Подробнее про HTTP/2, ALPN и сложности для NGFW записал в видеоролике.

Пилот NGFW. Какие функции проверять?

Краткий обзор функций NGFW, которые нужно проверять во время пилота.

Видео было сделано для партнеров Palo Alto Networks, чтобы показать что нужно обсудить с заказчиками, чтобы показать минимальный функционал.

Также видео подходит и заказчикам, чтобы объяснить интеграторам какой функционал нужен. )

Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)

Защита от DoH и DoT

Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Одной из областей, которой часто не уделяется должного внимания, является DNS. Контролируете ли вы свой DNS трафик?

Серьезность проблемы в том, что по данным Palo Alto Networks Unit 42 Threat Research, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.

 

Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.

 

Презентация Verisign по тому как Ransomware использует DNS.

При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.

Что такое зашифрованный DNS?

Система доменных имен (DNS) преобразует удобочитаемые доменные имена (например, адрес www.paloaltonetworks.com ) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.

 

Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или перехвата и перенаправления в нежелательные пункты назначения. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. В частности, зашифрованные протоколы DNS защищают от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом. 

 

За последние несколько лет были внедрены два протокола шифрования DNS:

1. DNS-over-HTTPS (DoH)

2. DNS-over-TLS (DoT)

Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.

 

Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.

DNS over HTTPS (DoH)

DNS внутри HTTPS

Этот протокол использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы «смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении», «затруднить анализ трафика DNS» и, таким образом, обойти меры корпоративного контроля ( RFC 8484 DoH, раздел 8.1 ). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.

Риски, связанные с DoH

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

 

И Google, и Mozilla реализовали возможности DoH в последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS. Microsoft также разрабатывает планы по интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи: PsiXBot теперь использует Google DoH, PsiXBot продолжает развиваться с обновленной инфраструктурой DNS и анализ бэкдора Godlua.) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.

 

Обеспечение видимости и контроля трафика DoH

В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https). 

Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.

 

Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:

В качестве промежуточной альтернативы, если ваша организация не полностью реализовала расшифрование HTTPS, NGFW все еще можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см.  Applipedia от Palo Alto Networks  и выполните поиск по фразе «dns-over-https») .

 

DNS over TLS (DoT)

DNS внутри TLS

В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS (RFC 7858 , Раздел 3.1).

 

Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 (RFC 7858, раздел 6).  Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.

Риски, связанные с DoT

Google реализовал DoT в своем клиенте Android 9 Pie и более поздних версиях, при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.

 

Обеспечение видимости и контроля трафика DoT

В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:

• Настройте NGFW для расшифровки всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.

• В качестве альтернативы можно полностью заблокировать движком App-ID трафик 'dns-over-tls' через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение 'dns-over-tls' или трафик через порт 853).

Доступна запись Palo Alto Networks Security Summit 2019 в Москве

27:00 "To Cloud or not to Cloud", Alexandre Delcayre 43:10 "Что является важным критерием в проектах ИБ", Александр Парамонов 44:30 "Ваши проекты 2019-2020 года: SDN, SD-WAN, SOAR, NG SOC, UEBA, XDR, HTTP 2.0, DNS Security, SSL Decrypt", Денис Батранков 1:24:38 Cсылки на прошлые вебинары Palo Alto Networks https://safebdv.blogspot.com/p/blog-page.html 1:28:10 Круглый стол по облакам с участием Ангара (Сергей Шерстобитов, Дмитрий Пудов), Сбербанка (Сергей Валуйских), Яндекс.Облако (Григорий Отребьев), Северсталь (Сергей Гусев) 2:23:40 "Arista и Palo Alto Networks - как улучшить безопасность ядра сети", Андрей Нуштаев 2:38:57 Опыт выбора NGFW в компании EPAM, Дмитрий Чернобай, ИТ директор EPAM Systems 2:50:00 Cortex XDR - English language 3:49:49 Cortex XDR - ответы на вопросы 4:59:17 "New Buzzwords, SOC, CSIRT, PSIRT, Next Gen SOC, Red/Blue Team, Shadow IT, Air GAP, Mimikatz, DFIR", Денис Батранков 5:11:10 "Интеграция Autofocus в SOC и автоматизация IoC через EDL и MineMeld", Денис Батранков 5:21:55 "Что такое TTP - Tactics, Techniques and Procedures", Денис Батранков 5:26:40 "Что делает бесплатная утилита MineMeld", Денис Батранков 5:30:18 Palo Alto Networks как источник аналитики в Big Data, Юрий Бутузов, ICL 5:52:40 "В фокусе пользователь, а не IP адрес" Игорь Булатенко, QIWI 6:19:38 RedLock и Aperture, Илья Осадчий, Tiger-Optics 6:44:50 Global Protect Cloud Service Palo Alto Networks и методики защиты удаленных офисов и мобильных устройств, Денис Батранков 7:35:35 SD-WAN, Сергей Козлов, Riverbed 8:06:10 Бесплатные утилиты SANS, Expedition, Migration Tool, UTD, Best Practice Assesment, SLR, Machine Learning для улучшения вашей безопасности, Денис Батранков 8:27:50 Награждение партнеров Palo Alto Networks, команда Palo Alto Networks