Преимущества анализа приложений 7 уровня в межсетевых экранах. Часть 1. Основы


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

    Почему появилась эта статья?

    Неоднократно приходил к коллегам-безопасникам, которые пользуются межсетевым экраном нового поколения и видел, что они продолжают писать правила по номерам портов. На мое предложение перейти писать по имени приложений, слышал «А вдруг так не заработает?». Если вам тоже «страшно» или непонятно зачем писать правила по приложениям, от эта статья для вас.


    ЧАСТЬ 1. Основы межсетевого экранирования


    СОДЕРЖАНИЕ

    Введение
    Определения
    Firewall
    L3 Firewall
    L4 Firewall
    L7 Firewall
    UTM
    NGFW
    Примеры
    Прокси-сервер
    Что такое USER-ID
    Заблуждения о Stateful Inspection: Состояние L4 vs L7
    Заблуждения о Stateful Inspection: Число сессий L4 vs L7
    Заблуждения о Stateful Inspection: Кластер L4 vs L7
    Часть 2. Влияние L7 Firewall на безопасность

    Введение


    Skype, TOR, Ultrasurf, TCP-over-DNS и еще несколько сотен приложений и туннелей спокойно проходят сквозь statefull inspection firewall и HTTP прокси. Многие средства защиты открывают соединения, но не проверяют, что ходит внутри них. Предлагаю разобраться, как контролируемо разрешать соединения приложений в новом поколении firewall, где правила пишутся по именам приложений, что соответствует 7 уровню модели OSI ISO. Такие межсетевые экраны имеют название Next Generation Firewall, межсетевой экран нового поколения или просто NGFW.
    Администратору межсетевого экрана нужно не только разрешить соединение, а еще гарантировать, что внутри разрешенного соединения ходит то, что вы хотели, включая проверки передаваемых файлов. Это называется безопасное разрешение приложений.

    Существует несколько важных отличий в работе с трафиком, которые понимаешь лишь когда переходишь на реальное использование правил, где критерием является приложение 7 уровня модели ISO OSI:

    • ИТ администратор видит, что NGFW визуализирует сетевой трафик, то есть показывает содержимое поля данных пакетов, имена пользователей и какое приложение работает и какие файлы передает.
    • ИТ безопасность видит, что NGFW обеспечивают безопасное разрешение приложений, поскольку более глубокий анализ данных в пакете позволяет увидеть вирусы, подключить отправку неизвестных файлов в песочницу, проверить тип файла, ключевые слова для DLP, проверить категорию URL, проверить что идет внутри SSL и SSH, сравнить с уже известными всему миру индикаторами компрометации, включить DNS фильтр и другие современные техники.

    Чтобы понять причины этого сравним журналы L4 и L7 firewall.
    А) Сравните запись в журнале L4 firewall, который разбирает только заголовок транспортного (четвертого) уровня модели OSI ISO — в данном случае TCP:

    Да, есть информация об источнике и получателе, можно догадаться по номеру порта 443, что внутри, с большой степенью вероятности (как говорят англичане) соединение SSL. Я лично не могу увидеть в этой записи какой-то инцидент. А вы?
    Б) Сравните запись в журнале L7 firewall для того же самого TCP соединения, где разбирается еще и сам контент передаваемый в поле данных TCP/IP:

    Здесь вы видите, что Иванов из отдела маркетинга выложил на Slideshare файл с пометкой «не для распространения». Это пример реального инцидента, где сотрудник выложил конфиденциальные планы развития компании на год в Интернет. Эта информация получена в L7 firewall на основе анализа того же самого соединения, что и выше у L4 firewall и сразу информации становится достаточно, чтобы понять, что был инцидент. И это совершенно другой подход к анализу трафика. Но, сразу предупрежу, что такой глубокий анализ накладывает серьезную нагрузку на процессор и оперативную память устройства.

    Иногда ощущается, что уровень детализации журналов в NGFW похож на уровень детализации в системах SIEM, которые собирают информацию по крупицам из разных источников. Именно поэтому NGFW один из лучших источников информации для SIEM.

    Определения


    Нужно подсветить термины, которыми мы будем дальше оперировать. У меня нет цели в деталях дать все определения.



    Семиуровневая модель OSI ISO – это модель взаимодействия между сетевыми устройствами, которая гласит, что существует 7 последовательных уровней абстракции взаимодействия: первый — физический, следующий канальный, сетевой, четвертый — транспортный, затем сессионный, представления и седьмой уровень – приложений (см. картинку выше).

    Каждое сетевое устройство работает на своем уровне абстракции: веб сервер и браузер – на уровне приложений (уровень 7 или кратко L7), маршрутизаторы — общаются друг с другом на канальном (2) и сетевом уровне (3), когда передают друг другу фреймы и пакеты.

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

    И вот глубина анализа сетевых пакетов может отличаться. Анализируют ли они 4 или 7 уровень — в этом есть важное отличие.

    Firewall


    Межсетевой экран (МСЭ), Network Firewall– это сетевое устройство, которое делит сеть на сегменты с разными политиками безопасности и контролирует эти политики. Например, сегмент Интернет – там можно все что угодно. И сегмент вашего ЦОД – там можно работать только выделенному списку сотрудников по разрешенным приложениям. Внутри одного хоста VMware может быть несколько виртуальных сетей с виртуальными машинами и разными политиками доступа к ним.

    Политика безопасности firewall содержит правила, которые приводит в действие программный код устройства, анализируя каждый фрейм и пакет пришедший и исходящий с firewall. В правилах firewall задаются критерии проверки (квалификаторы), по которым принимается решение пропускать или блокировать трафик. Примерами квалификаторов в правилах являются: адрес, порт, приложение, пользователь, зона. Межсетевой экран последовательно, правило за правилом, сверху внизу по списку просматривает критерии и если входящий трафик соответствует всем критериям правила, (логическая операция «И» между критериями) то применяется указанное действие: заблокировать или пропустить. Действие выполняется как для первого пакета, так и для всех последующих пакетов одного TCP/IP соединения.

    Существуют разные типы и реализации firewall. Мы рассмотрим классификацию по степени используемой глубины анализа трафика: L3, L4 и L7.

    L3 Firewall


    L3 firewall – это межсетевой экран, который пропускает через себя трафик и анализирует только заголовки IP протокола, то есть адрес откуда и куда идет трафик. Такие межсетевые экраны называют пакетный фильтр. Правила имеют название «список доступа» или access-list (ACL) и этот функционал на сегодня работает практически в любом маршрутизаторе и операционной системе. Такой анализ не требует серьезной нагрузки на процессоры и память firewall.

    L4 Firewall


    L4 firewall – это межсетевой экран, который пропускает через себя трафик и проверяет заголовки протоколов 4 уровня: TCP, UDP, ICMP, то есть основными критериями проверки для пропуска трафика является IP адреса и порты TCP/UDP или сервисы ICMP.

    Также в L4 firewall появляется понятие stateful inspection, когда каждый проходящий запрос запоминается и хранится состояние запроса для того, чтобы разрешать необходимые ответные соединения. То есть появляется понятие инициатора соединения, что логично в сетях, построенных на клиент-серверной технологии. Такой межсетевой экран тратит память на хранение данных о каждом соединении, то есть появляется ограничение на максимальное количество хранимых одновременных сессий в памяти. В L4 firewall уже не нужно писать ответное правило для обратного соединения, как это требуется в L3 firewall, потому что на основе состояния соединения, межсетевой экран автоматически разрешает обратные соединения. То есть L4 firewall удобнее, чем пакетный фильтр.

    Современные L4 firewall хранят состояние не только TCP, UDP и ICMP, но и отслеживают взаимодействие некоторых L7 приложений. Например, состояние FTP, HTTP, SIP, и другие приложения, что уже зависит от конкретной реализации firewall. Нужно задавать производителю L4 firewall вопрос: какие конкретно приложения поддерживает их движок stateful inspection firewall.



    L7 Firewall


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

    Нагрузка на L7 firewall гораздо выше, поскольку его процессор должен постоянно анализировать мегабайты поля данных, которые передает приложение, в то время как L4 firewall проверяет только несколько байт заголовка IP пакета с адресами источника и получателя и портами. Размер буфера для хранения состояния каждого приложения L7 требуется гораздо больше, поскольку данных на L7 передается больше, чем просто в заголовке TCP/IP. Из-за выросшего размера буфера при использовании анализа приложений, количество одновременно хранимых в памяти сессий у L7 firewall меньше L4 firewall при том же объеме памяти. Поскольку L7 firewall видит по контенту что за приложение идет по сети, то номер порта не несет особенного смысла и правила можно писать по имени приложения L7. Кроме того современные приложения генерируют много соединений и все эти соединения являются частью одного приложения. Этот вид firewall позволяет вернуть контроль за современными динамическими приложениями, работающими по любому порту, например, teamviewer, bittorent, tor, о которых L4 firewall ничего не знает. То есть L7 firewall в современных реалиях нужен, если в сети нужна безопасность.
    Если после прочтения данной статьи вы продолжите использовать L4 firewall то, это значит, что на безопасность вам наплевать.



    UTM




    UTM – это сетевое устройство, внутри которого установлено несколько различных компонентов защиты, которые последовательно анализируют проходящий через устройство трафик. Ядром UTM является L4 firewall, система предотвращения атак (IPS), антивирус, анализ категорий URL в HTTP и HTTPS. Часто UTM еще реализуют функции VPN шлюза. Управление всеми этими компонентами как правило осуществляется из нескольких разных систем управления. Трафик внутри UTM последовательно проходит через модули фильтрации и на выходе остается чистый трафик, который разрешен политиками безопасности каждого модуля. UTM может быть использован как платформа для других функций: защита от вирусов, IPS, DDoS, QoS, DLP, DNS фильтр, базы индикаторов компрометации Threat Intelligence, защита от фишинга и так далее (зависит от производителя).

    Притча про человека, который заказал семь шапочек из одной шкуры, написана в том числе для покупателей UTM: чем больше функций вы захотите после покупки включить, тем большую нагрузку будут нести процессора UTM для анализа одного и того же объема трафика. Больше функций – меньше скорость устройства.


    Идея UTM – нагрузить один процессор как можно большим количеством функций стала эволюционным тупиком, потому что число функций росло и выдерживать всю эту нагрузку процессоры не могли. Сегодня, несмотря на заявленные хорошие функции, никто не включает в UTM весь функционал, чтобы исключить задержки трафика.
    Цель UTM: реализовать на одном сервере как можно больше функций, чтобы удешевить устройство для пользователя.
    Сейчас производители UTM стали ставить движки анализа приложений 7 уровня, чтобы говорить, что они NGFW, чем сбивают с толку потребителя. Однако это легко распознать, если посмотреть в политику безопасности: правила по-прежнему базируются на критериях проверки полей L4. А для фильтрации L7 приложений используется отдельный раздел настроек, то есть приложение L7 не является квалификатором, как должно быть в L7 firewall. Распознавать приложение L7 и использовать приложение L7 как критерий политики безопасности – это «две большие разницы».

    NGFW


    NGFW – это сетевое устройство, внутри которого реализован L7 firewall. Поскольку квалификатором основным становится имя приложения L7, то правила пишутся по новым критериям. В NGFW всегда работает динамическое сопоставление IP адресов пользователи сети, поэтому имя пользователя тоже становится квалификатором(критерием). NGFW включает в себя функции расшифрования SSL/TLS и SSH для распознавания приложений и атак внутри них, IPS, антивируса, URL фильтрации.

    Термин NGFW сначала был придуман маркетингом компании Palo Alto Networks. Но постепенно прижился на рынке и все производители UTM сейчас тоже называют себя NGFW. И действительно, NGFW тоже выполняет несколько функций одновременно, почему же тогда NGFW не UTM? Отличие важно знать. Оно в том, что в NGFW функции безопасности приложений (IPS, антивирус, URL фильтрация) ускорены аппаратно. Существуют специализированные аппаратные чипы: IPS проверяет атаки на своем чипе, антивирус сигнутуры на своем, расшифрование SSL — на своем и так далее. Разделение функций по разным процессорам дает возможность запускать защитные функции параллельно и не ждать, когда закончит работать предыдущая функция, как в UTM. Для примера в аппаратных межсетевых экранах компании Palo Alto Networks установлено до 60
    специализированных процессоров компании Cavium выполняющих ускорение функций безопасности, сетевых функций и управления. Важно, что NGFW содержат единый программный интерфейс управления всеми функциями одновременно.
    Идея NGFW в отличие от UTM – реализовать каждую функцию на отдельном процессоре, который специализирован под требуемый функционал.
    По такой же схеме когда-то пошли производители компьютеров, которые вынесли функции математики и графики в отдельные математические и графические сопроцессоры. Поэтому в NGFW стоят отдельные процессоры под распознавание приложений L7, под расшифрование SSL/SSH, под проверку сигнатур антивируса, проверку сигнатур IPS и так далее. Это позволяет включить все функции одновременно, без деградации и задержки трафика в устройстве на время проверки. Почему компьютеры без графических акселераторов никто уже не покупает, а межсетевые экраны без ускорения покупают? Потому что ускорение не нужно на небольших скоростях, но когда скорости анализа трафика выходят за 1-5 Гигабит — реализовать все функции безопасности уже невозможно без ускорения.

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

    Примеры


    Пример политики L7 в Palo Alto Networks NGFW

    Зачем может потребоваться URL категория, как квалификатор? Например, вы можете части сотрудников разрешить все-таки посещать вредоносные сайты браузером, но заблокировать им скачивание файлов.
    Пример политики Palo Alto Networks с использованием проверок Host Information Profile и URL категорий.

    В этой политике также задействована проверка наличия хостовой защиты TRAPS в колонке HIP Profile, которая не даст зайти на сайт с вредоносным кодом и эксплойтами, без установленной защиты на компьютере. TRAPS это агент защиты от вредоносного кода и эксплойтов.

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



    Прокси-сервер


    Прокси-сервер– это устройство, которое терминирует на себе трафик какого-то приложения, проверяет это трафик различными методиками и отправляет этот трафик дальше. Чаще всего используются в сетях прокси-сервера для протоколов HTTP и HTTPS. Поскольку UTM и NGFW анализируют потоки HTTP и HTTPS прозрачно, не требуя явно указывать настройки прокси-сервера у клиентов, то HTTP прокси постепенно исчезают из компаний.



    Что такое USER-ID


    В NGFW был придуман механизм идентификации пользователей. Алгоритм либо работает внутри, либо запускается на внешнем агенте. Буду называть это механизм USER-ID. USER-ID создает и поддерживает таблицу соответствия имени пользователя и его текущего IP адреса. Также бывает, что в таблице есть и значение и порта для данного пользователя, если пользователи работают через VDI (то есть пользователи идут с одного адреса и их можно различить только по портам).
    image
    Перечислю механизмы USER-ID в Palo Alto Networks
    1. Server monitoring: User-ID агент читает события Exchange Servers, domain controllers или серверов Novell eDirectory
    2. Client probing: User-ID агент опрашивает Windows клиентов по WMI
    3. Terminal services agent: TS агент раздает разным пользователям разные диапазоны TCP/UDP портов для работы с Windows/Citrix Terminal Servers
    4. Разбор сообщений Syslog: User-ID агент читает syslog соообщения об аутентификации от различных систем, wireless controllers, 802.1x устройств, Apple Open Directory servers, proxy серверов, VPN шлюзов, Сisco ISE
    5. Аутентификация через клиент GlobalProtect: логин и пароль на VPN + можно добавить MFA
    6. Аутентификация через через Captive Portal: Web traffic аутентифицируется по NTLM или AAA web формой (Captive Portal используется в Московском метро и кафешках. NTLM позволяет делать аутентификацию прозрачной)
    7. XML API: информация о входе и выходе передается User-ID агентом специальными командами через REST API firewall
    8. X-Forwarded-For: прокси-сервера заполняют это поле в HTTP запросе, чтобы было понятно кто там прячется за прокси

    Чтение журналов с контроллеров Active Directory — самая часто используемая функция в USER-ID. Агент USER-ID выполняет периодически чтение сообщений из журналов AD, где записано какой пользователь с какого IP адреса авторизовался, именно из них USER-ID узнает о том по какому адресу пользователь и хранит это внутри NGFW, например для Windows 2008/2012 это сообщения:
    — 4768 – Authentication Ticket Granted
    — 4769 — Service Ticket Granted
    — 4770 – Ticket Granted Renewed
    — 4264 – Logon Success
    Для чтения журналов агенту USER-ID нужен доступ с правами Even Log Reader.

    Заблуждения о Stateful Inspection


    Отдельную главу я должен посвятить этому святому каждому сетевому инженеру и безопаснику понятию. Нужно подчеркнуть и дополнить важные вещи, которые часто упускают на курсах по межсетевым экранам. Если вы уже изучали основы stateful inspection, то скорее всего у вас есть несколько заблуждений.

    Есть одно заблуждение, которое я иногда вижу у коллег. Внимание! Stateful inspection — это не только про состояние соединения TCP, UDP или ICMP! Это еще и про состояние других более сложных протоколов и приложений: FTP, SIP, RPC, SMTP, SMB и так далее!
    Пример.

    Протокол FTP — это протокол уровня приложений. И в нем есть команда PORT, которая может назначать новое TCP подключение. Любой firewall, который позиционирует себя как stateful inspection firewall, должен контролировать команды FTP и видеть команду PORT и разрешать соединение на порт и адрес, который там запрошен. И это еще не все: firewall еще и должен подменять параметры команды PORT и вставлять правильный адрес, если FTP сервер работает за NAT.
    То есть в любом современном L4 firewall есть компонент, который подглядывает за L7 уровнем. И такой протокол не один: еще есть HTTP, RPC, и другие… И такие анализаторы протоколов 7 уровня называются Application Layer Gateway (ALG).
    Пример.

    Самый «любимый» одновременно у сетевиков и безопасников – это ALG для SIP, с которым многие, кто настраивает SIP ALG на L4 firewall наелись проблем, и часто заканчивается его отключением.
    То есть уже в L4 firewall есть зачатки анализа протоколов 7 уровня. L4 firewall отличаются друг от друга количеством реализованных ALG. Когда вы сравниваете обычные L4 firewall, то справедливый вопрос системному инженеру производителя будет: сколько протоколов и приложений поддерживает ваш движок Stateful Inspection? Как правило никто не отвечает.
    Получается, что L7 firewall — это тоже stateful inspection firewall, но который анализирует и хранит статус ВСЕХ приложений, а не только выборочно, как L4 firewall.


    Второе заблуждение вносят сами производители firewall. Возьмите любой datasheet, где производитель пишет такой параметр, как «число одновременных сессий». Вопрос к производителю следующий: сессии каких именно протоколов и приложений измерялись и был ли включен хотя бы stateful для TCP, не говоря уже были ли проверки для L7 уровня?

    Мы знаем, что у каждого протокола или приложения есть состояние, которое помнит firewall. И для хранения этого состояния нужно выделить буфер в памяти устройства. По сути, параметр «число одновременных сессий» означает сколько буферов для хранения состояний можно уместить в памяти устройства. Нужно понимать, что для L4 firewall чаще всего измеряют этот параметр для голого TCP или даже UDP. То есть для TCP нужен буфер, в который умещается только IP и порт соединения. Однако в тесте для L7 приложений, например, HTTP этот буфер будет значительно большего размера, ведь хранить, например, параметры запроса GET внутри HTTP требуется больше памяти. А память не резиновая. Соответственно, если производитель пишет такой параметр как «число одновременных сессий», то он должен писать:
    • был ли это просто тест работы в режиме свитча/роутера, c выключенным stateful inspection,
    • был ли это режим L4, где он запоминал только заголовки TCP/IP,
    • было ли какое-то приложение L7 уровня взято для теста.

    Правильно L7 firewall измерять на числе одновременных сессий HTTP, на пакетах разной длины: 64Кб, 44Кб, 16Кб, 1.5Кб. Понятно, что если каким-то производителем все измерения были сделаны на UDP 1518 байт, то скорее всего в вашу сеть такое устройство не подойдет, поскольку заставить ваших пользователей посылать только UDP пакеты длиной 1518 байт – не получится, а уж тем более заставить отвечать такими пакетами сервера HTTP. Нужно сказать такому производителю, что производительность L7 firewall нужно измерить хотя бы на трафике с протоколом HTTP. Из известных компаний, которые проводят такие тесты публично: компания NSS Labs.
    Сами производители firewall проводят тесты на заказ в своих лабораториях, которым можно заказать свой профиль трафика, например: 30% трафика HTTPS, 10% трафика SMB, 10% трафика FTP и так далее.
    Пример.

    После проверки на генераторе трафика IXIA устройства одного из производителей UTM:
    • в режиме L4 firewall — 4 000 000 одновременных сессий,
    • в режиме L7 firewall — 200 000 одновременных сессий.

    Это показатель того, что буферов для сессий L7 в памяти устройства меньше из-за их большого размера.

    И, кстати говоря, также будет и с общей производительностью устройства: с выключенными проверками контента приложений межсетевой экран работает в 10 раз быстрее, чем с включенными. Использовать только анализ заголовков 4 уровня для ускорения устройства можно, но безопасности уже никакой.

    Третий важный момент – работа в кластере. Все межсетевые экраны должны работать в кластере, потому что если один межсетевой экран перестает работать, то его задача «лечь грудью» и заблокировать весь трафик — такова теория построения защиты на базе межсетевых экранов. Пока «сломанный» firewall блокирует трафик, задачу по пропуску легитимного трафика должен взять на себя соседний firewall. А что же будет с соединениями, которые шли через первый? Скорее всего первый firewall передавал состояние всех соединений второму, но вот передавал ли он соседу только состояние IP заголовков или полностью состояние всех приложений L7 уровня: а ведь там были какие-то SSL соединения которые были расшифрованы и над ними трудился IPS и антивирус – они собирали пакеты в буфера, чтобы проверять содержимое. И тут оказывается тоже L4 и L7 firewall отличаются: передать состояние L4 не то же самое, что передать состояние L7. Это тоже важно понимать.

    Существует еще одно заблуждение, что L7 firewall могут работать в кластерах более двух устройств — это неверно, поскольку объем передаваемых данных L7 растет экспоненциально с каждым новым узлом в кластере и обработка данных даже двух соседок превышает затраты по обработке данных своего же устройства. Именно поэтому кластеры больше двух устройств работают только обмениваясь заголовками L4, и при переключении кластеров все функции анализа приложений и защиты перезапускаются.

    Поэтому нужно грамотно сравнивать L4 и L7 firewall, также как когда вы сравниваете подходит ли вам легковой автомобиль и танк на войне. L7 firewall для повышения безопасности вашей сети проделывает более сложную работу, гораздо больше работы идет на его процессорах и ему нужно больше памяти для хранения состояния ваших приложений! Все это нужно делать для безопасности.

    Часть 2. Влияние L7 Firewall на безопасность

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Вам удобно разрешать приложение VNC по имени или вы помните все порты, которые ему нужны и разрешаете по портам?

    Поделиться публикацией

    Комментарии 23

      –1
      L7 firewall – это межсетевой экран, который пропускает через себя IP трафик сети и проверяет и заголовки 4 уровня и сегмент данных каждого IP пакета, то есть понимает L7 трафик уровня приложений, вплоть до того какие файлы передаются и в каком направлении

      В том же ssh, https и sftp что он видит в сегменте данных то? Хлам? Есть какие-то способы определить что там происходит кроме объёма трафика?
      Так-то завернуть vpn в https не особо проблема.
      Поэтому в NGFW стоят отдельные процессоры под распознавание приложений L7, под расшифрование SSL/SSH

      если бы трафик ssl можно было расшифровать силами одного-двух-сотни процессоров в реальном времени этим протоколом не пользовались бы. Тут не очень понятно.

      А всё. Нашел. Оно работает либо если у вас есть закрытые ключи обменивающихся данными, что как-то странно. Либо как банальный MITM что палевно. Никакой магии и расшифровывания ssl нет.
        0
        У специалистов в русском языке есть разница в терминах: расшифрование — это когда вы _знаете_ ключ, дешифрование — когда ключ _неизвестен_ и вы взламываете алгоритм криптографический. И вы правы, это не дешифрование, а расшифрование. В английском это один и тот же глагол: decrypt.
        Да, вы
        — либо расшифровываете методом MITM и тут главное создать trust chain в PKI, например сделать Firewall как Subordinate CA вашего же AD,
        — либо грузите закрытый ключ вашего WEB сервера в устройство — и тогда это прозрачно для пользователя.
        Вы это видео рекомендую для углубления знаний по SSL/TLS, SSH Decrypt https://www.youtube.com/watch?v=BMiOCJnFBpA
          0
          Хм. Видео с отключёнными оценками и комментариями определённо стоит доверять. Там есть какие-то иные предложения кроме подмены корневых сертификатов или MITM атак?
          А. Ок вижу. Действетельно напутал с терминологией. Скучный путь. И как-то, лично мне, сложно считать это повышением уровня безопасности.
            0
            PA-5050, вот версия Пало Альто для 10гбит/с анализ приложений. Там в списке ограничений данной версии указано «Max SSL inbound certificates — 300», т.е. можно залить 300 сертификатов, владельцем которых являетесь вы, чтобы браузер не ругался на MITM. У старших версий кол-во сертификатов больше.
            www.cisco.com/c/en/us/td/docs/security/firepower/623/fdm/fptd-fdm-config-guide-623/fptd-fdm-ssl-decryption.html а вот тут написано как Cisco декриптит SSL сертификаты в FirePower, все как написано сверху.
              0
              Уже вышло новое поколение, которое быстрее расшифровывает SSL. Сравните параметры той же 5050 и 5220 из нового поколения https://www.paloaltonetworks.com/products/product-comparison.html?chosen=pa-5220,pa-5050
              У SSL расшифрования есть несколько тонкостей, например, не все сайты и приложения разрешают делать MITM. Поэтому нужно обязательно вести список исключений, вот так он выглядит
              https://docs.paloaltonetworks.com/pan-os/8-0/pan-os-admin/decryption/decryption-exclusions/palo-alto-networks-predefined-decryption-exclusions
              image
              Вообще это будет описано в третьей части.
                0
                Думаю вы сами не забудете уточнить в третей части, но мало-ли. Как сотрудник IT департамента организации владеющей кластером от PaloAlto за не одну сотню кило-баксов, я хотел-бы, в контексте расшифровки SSL, подчеркнуть одну важную деталь:
                Это высокотехнологичное оборудование имеет тенденцию раз-другой в год слетать с катушек — сеть рассыпается. Начинается стандартный цирк: звонок в TAC, ескалад, лечение. Причины/объяснения всегда разные и, как по мне, зачастую сомнительные. Суть проблемы не в этом, а в том, что в процессе разрешения «сбоя», TAC с руками и ногами находиться в вашей системе и 'de facto' все ваши приватные ключи перестают быть таковыми.
                Уважаемые коллеги должны трезво взвешивать нужна-ли им такая безопасность и такой ценой…
                  0
                  мало кто доверяет в форумах «анонимным доброжелателям». Если у вас есть что-то по существу и с фактами, то написать можно в личку, куда я Вам уже написал для сохранения вашей приватности.
                    0
                    По существу хотелось-бы увидеть в третей части нечто вроде: «все новейшие PaloAlto оснащены аппаратными HSM и к приватным ключам не имеет доступа никто», «при общении с TAC, последний никогда не получает доступа к системе клиента и передаваемые диагностические данные всегда вычищены от критичной для безопасности информации». Ну а если такого написать нельзя то можете хотя-бы процитировать меня:

                    «Суть проблемы не в том что иногда сбоит, а в том что при SSL расшифровке в PaloAlto (и других решениях) оказываются одновременно приватные ключи и посторонние vis-a-vis компании люди. И кстати доступ они получают ведь не только в случае сбоя, а и в случае помощи в настройке всяких плюшек. Я могу еще понять когда приходиться пересоздать новый сертификат для VPN, менять пароли, и т.д. но потенциальная потеря приватного ключа — это инцидент по безопасности.

                    А теперь представте смену сертификатов для разных сторонних сервисов — IMHO ситуация когда решение хуже проблемы.»

                    ПС Какие конкретно у нас были и есть проблемы — вопрос частный и по большому счету к делу не относиться. Мне кажется бессмысленным обсуждать тип и частоту проблем и переходить на личности. Проблемы были, есть и будут — такова жизнь: просто некоторые «архитектурные» решения имею серьезные подводные камни.
                      0
                      Не принимается довод. Извините. Странный вектор угроз. Первый раз слышу, что техподдержка представляет для кого-то угрозу, она, наоборот, вам дается в помощь. Вы все компании, которые вам помогают обвиняете в краже у вас секретных ключей? Или только избранные?
                      Вы же имеете доступ к секретным ключам своей компании и хвалитесь об этом в Интернет, зачем? Это серьезный инцидент по безопасности. Социальную инженерию тоже никто не отменял. Как другие сотрудники могут вам доверять теперь доступ к секретным ключам?
                      Вы пожалуйста взвешивайте свои слова, когда пишете обвинения. Вам люди пришли помогать с настройкой — а вы их обвиняете в краже? Супер!
                        0
                        В нормальной ситуации доступ к приватному ключу сертификата сервиса имеет максимум 1-2 админа. Эти 1-2 админа `a priori` обеспечили «Forward Secrecy» для конкретного сервиса и в случае утечки приватного ключа просто перевыпустят сертификат, а старый внесут в CRL своего CA.
                        В вашем мире вы собираете в одном месте приватные ключи десятков-сотен сервисов. Эти ключи доступны людям управляющим вашим файерволом, не названому количеству сотрудников вендора, а то и вообще половине планеты (если плохо защитили коннект при передаче диагностического дампа) — помним о СОРМ и прочих — недопустимая ситуация.

                        Мне непонятна ваша «эмоциональность»:
                        Вам люди пришли помогать с настройкой — а вы их обвиняете в краже?
                        При чем тут все это?

                        IMHO В идеале приватного ключа сертификата не должно быть ни у кого, но аппаратный HSM дорого и не всегда реализуем.

                          0
                          В вашем мире вы собираете в одном месте приватные ключи десятков-сотен сервисов. Эти ключи доступны людям управляющим вашим файерволом, не названому количеству сотрудников вендора, а то и вообще половине планеты (если плохо защитили коннект при передаче диагностического дампа) — помним о СОРМ и прочих — недопустимая ситуация.

                          Вообще перестал понимать. Ключи доступны половине планеты? Ничесе. Вы можете объяснить как половина планеты крадет ваши ключи и главное зачем этой планете ваши ключи? Почему половина планеты прослушивает ваши диагностические дампы и как она умудряется вытащить секретный ключ из HSM?
                            0
                            Простите но во мне растет уверенность что вы просто не понимаете что такое сертификаты, как они работают и зачем это делается — тревожный симптом. Я отвечу на эти ваши вопросы но далее видимо прекращу этот бессмысленный диалог.

                            Вы можете объяснить как половина планеты крадет ваши ключи
                            Как я написал «если плохо защитили коннект при передаче диагностического дампа» (mail, ftp, а то и просто слабое шифрование) позволяет любому человеку находящемуся между отправителем и получателем перехватить данные которые в конкретном контексте могут содержать приватные ключи хранящиеся в апплайансе.

                            и главное зачем этой планете ваши ключи?
                            чтобы делать то что сертификаты призваны не допускать: расшифровка трафика между пользователем и сервисом, создание фальшивых сервисов, и т.д. Если-бы защита была не нужна — ею бы не занимались.

                            Почему половина планеты управляет вашим файрволом и как она умудряется вытащить секретный ключ из HSM?
                            Не знаю откуда вы это высосали. Перечитайте мой комментарий.
                              0
                              да, давайте замнем для ясности. ок?
                    0
                    Риски утечки приватного ключа есть. С другой стороны, если взять классический https inspect, то mitm внешний злоумышленник сможет провести, уже преодолев защищаемый периметр. Тут как говорится Тушите свет.

                    По части американских «партнёров», если их саппорт с руками сидит на периметровой защите, то тут и помимо банальной кражи сертификатов, можно много чего накрутить. Это уже вопрос доверия к вендору.
              0
              Расшифровать не получится. Но! Я работал в компании на 5000 человек с ~15 офисами по миру и я могу сказать, как мы поступали с SSL. Да, Вы абсолютно правы когда сказали, что «Так-то завернуть vpn в https не особо проблема.», но тогда будет видно, что у пользователя огромный поток данных уходит/приходит по SSL и это повод изъять у него комп, а с самим пользователем очень серьезно поговорить. Конечно есть способы балансировки SSL между разными гейтвейями. В целом конечно рано или поздно отловить доброжелателя можно (при условии того, что вы собираете статистику и у вас есть SOC который это всё анализирует), но и как показывает практика — если у человека есть цель подгадить и у него есть техническая экспертиза выше среднего, то остановить его получается не сразу, а иногда не получается вообще. И да: «Никакой магии и расшифровывания ssl нет.» — именно так и именно это иногда очень тяжело донести до ТОПов. В целом L7 FW дают понимание чем люди занимаются на работе и в 99% случаев в компаниях до 200 человек этого более чем достаточно!
                0
                Спасибо за развёрнутое объяснение.
                Про то, что 'доброжелателей' можно отслеживать по аномалиям в трафике слышал, хотя в живую не разу не щупал.
                Просто в статье куча красивостей про анализ HTTP трафика, который в современных реалиях не особо актуален, а лет через 5 дайб-г его станет исчезающе мало. А вот для работы с SSL уже тупо воткнуть файрвол не достаточно. Нужен ещё и пряморукий админ для всего этого дела, который сможет наделать дыр в трафике, не нанеся вреда внешней безопасности либо подключить адекватную аналитику по частоте/объёму.
                  0
                  Я знаю, что NGFW ко всему прочему для https анализируют ssl-сертификат. В своё время брал fortigate на тест — он красиво разрисовывал популярные сервисы и приложения именно на основе SSL certs. Опять же «в 99% случаев в компаниях до 200 человек этого более чем достаточно», т.е. было видно сразу тех, чей https трафик состоял на 90% из facebook, vk и пр. полезных и важных сервисов, посещаемых в рабочее время — контент ест-но виден не был, но общее представление о traffic profile это давало. У нас админы сидели в отдельном VLAN и для этого VLAN были одни пороги срабатывания по SSH трафику, а например если на 22-й порт или на 1194 начинало переть много трафика например из сегмента маркетинга, то это был повод сгенерировать алерт. Я к чему: NGFW скорее полезная штука, чем бесполезная, но и эта полезная штука не всесильна. В своё время когда появился MPLS люди его пихали во все дыры не разбираясь в вопросе и не понимая, что MPLS — это multiprotocol label switching, а не magic problem solver.
                    0
                    Самое сложное, что нас ждет — HTTP 2.0. Вот там будет весело трафик анализировать. Ну и QUIC тоже доставляет удовольствие — его приходится запрещать, чтобы Chrome обратно переходил на SSL/TLS и его можно было расшифровать.
                0
                Объясните пожалуйста как в примере с выкладываем файла с секретной презентацией в журнал попало имя пользователя? Я немного не понимаю как из http сессии на роутере вытащить имя пользователя под которым запущена программа которая эту сессию открыла. Или там какое то другое имя пользователя?
                Может на компьютерах конечных пользователей должно быть программное обеспечение, которое дополнительно маркирует ip пакеты?

                А если бы менеджер выкладывал не саму презентацию, а архив с этой презентацией, попала бы в журнал информация что это поверпоинт и секретно?
                  0
                  по-моему это связано с AD, т.е. файрвол связан с базой.
                    0
                    В NGFW существует механизм идентификации пользователей. Он реализован либо встроенным, либо внешним агентом, буду называть это механизм USER-ID. USER-ID создает и поддерживает таблицу соответствия имени пользователя и его текущего адреса. И бывает, что в таблице есть и значение и порта, если пользователи работают через VDI (то есть пользователи идут с одного адреса источника и их можно различить только по портам).
                    image
                    Перечислю механизмы USER-ID в Palo Alto Networks
                    1. Server monitoring: User-ID агент читает события Exchange Servers, domain controllers или серверов Novell eDirectory
                    2. Client probing: User-ID агент опрашивает Windows клиентов по WMI
                    3. Terminal services agent: TS агент раздает разным пользователям разные диапазоны TCP/UDP портов для работы с Windows/Citrix Terminal Servers
                    4. Разбор сообщений Syslog: User-ID агент читает syslog соообщения об аутентификации от различных систем, wireless controllers, 802.1x устройств, Apple Open Directory servers, proxy серверов, VPN шлюзов, Сisco ISE
                    5. Аутентификация через клиент GlobalProtect: логин и пароль на VPN + можно добавить MFA
                    6. Аутентификация через через Captive Portal: Web traffic аутентифицируется по NTLM или AAA web формой (Captive Portal используется в Московском метро и кафешках. NTLM позволяет делать аутентификацию прозрачной)
                    7. XML API: информация о входе и выходе передается User-ID агентом специальными командами через REST API firewall
                    8. X-Forwarded-For: прокси-сервера заполняют это поле в HTTP запросе, чтобы было понятно кто там прячется за прокси

                    Первая — самая часто используемая функция в USER-ID. То есть выполняется периодически чтение сообщений из журналов AD, где записано какой пользователь с какого IP адреса авторизовался, именно из них USER-ID узнает о том по какому адресу пользователь и хранит это внутри NGFW, например для Windows 2008/2012 это сообщения:
                    • 4768 – Authentication Ticket Granted
                    • 4769 — Service Ticket Granted
                    • 4770 – Ticket Granted Renewed
                    • 4264 – Logon Success

                    Добавил в статью.
                    0
                    для фильтрации url от Роскомнадзора Palo Alto не подойдет да? Я там видел ограчение в 100,000 урлов.
                      0
                      Некоторые используют. Судя по копии базы РКН github.com/zapret-info/z-i на сегодня 18 января в базе всего лишь 8738 URL в базе. Так что влезет в объект External Dynamic List или в Custom URL Category.
                      Роскомнадзор блокирует и по URL и по IP адресу.
                      IPшников значительно больше (3699600 на 18 января 2019 судя по usher2.club) и они уже не влезут, поскольку даже в старших моделях ограничение = 150000 IP адресов.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое