Задача написания правил на межсетевом экране непростая, потому что правил много. Я встречал межсетевые экраны, где было 80 тысяч правил. Чтобы не ошибиться в добавлении новых правил применяются различные методы, но самое сложное - это исправлять текущие правила, поскольку ты должен изучить какие соединения были разрешены и не знаешь можно ли часть из них запретить, если тебе кажутся они нелегитимными.
Я уже рассказывал про встроенный оптимизатор политик в NGFW, который позволяет узнать сколько разных приложений ходит по одному правилу и либо сузить этот список, либо создать несколько новых правил для "лишних" приложений. Это реально упрощает задачу по "снижению площади атаки" сервера, а точнее по снижению числа возможных методик обхода межсетевого экрана.
Обычно в колонке Application администраторы пишут ANY, то есть они не хотят думать какие конкретно приложения нужны данному источнику. Ну и для справедливости надо сказать, что и в колонке Service также часто вижу ANY - либо никто не знал какой порт нужно открыть, либо открыли временно и забыли.
Существует утилита Expedition, которая позволяет сделать автоматический анализ журналов и правил и также автоматически проставить в колонку Application нужные приложения, которые там и так ходят и которые вы, наверняка, хотели сами вписать туда, но руки не дошли сделать это несколько тысяч раз.
В интерфейсе это выглядит вот так.
Видно, что в тех правилах, где стояло any и шли приложения L7, Expedition предлагает добавить эти приложения явно в правило. То же самое и если, уже были приложения, допустим ssl, и утилита видит в журнале, что там не все возможные варианты ssl, а конкретные совершенно сервисы, использующие ssl, то она разрешает именно эти. Или наоборот, вы разрешили больше приложений, ходят не все - она предлагает удалить ненужные.
Автоматизация позволяет для всех ваших тысяч текущих правил межсетевого экрана просканировать журналы трафика, сопоставить с тем, какие правила какие приложения разрешили и автоматически создать новые, более точные правила.
В общем утилита чудесная. Она бесплатная и скачивается прямо с портала
NGFW в тренде. Когда Palo Alto Networks придумала и реализовала новую методику SP3 безопасного разрешения приложений в 2007 году, то это задало новый "золотой стандарт" построения межсетевых экранов и политик безопасности и упростило защиту сетей. Чтобы к нему подступиться нужно создать свою лабораторию, которая занимается созданием и поставкой сигнатур приложений, атак и вредоносного ПО, TI, проверками файлов в песочнице и прочей динамической начинкой устройств. Затем нужно нанять программистов, которые будут своевременно реализовывать новые технологии, не забывая про параллельно развивающиеся ИТ технологии: контейнеризацию, микросегментацию, SD-WAN, HTTP/2 и др. Всю сложную работу взяли на себя разработчики и исследователи и автоматизировали ее. И это все это упростило жизнь заказчикам.
Через NGFW удобно сделать удаленку!
Тихое пространство рынка NGFW стало самым обсуждаемым сегментом нашей индустрии в последние месяцы, просто потому, что тут есть VPN и подключать сотрудников по VPN, да еще защищать сотрудников через удобный интерфейс - хотел каждый здравомыслящий ИТ специалист во время коронавируса.
А как выбрать NGFW?
Однако, каждый новый производитель, придя на этот рынок, принес свое видение NGFW. Если посмотреть на рекламу, то оказывается есть NGFW без правил по приложениям, или без правил по пользователям. Оказывается скорость NGFW можно измерить, выключив все функции NGFW; скорость HTTPS можно измерить без проверки сертификатов SSL и категории URL. И самое эпическое - оказывается скорость NGFW можно измерить на UDP трафике 1518 байт, куда вы там вирусы запихиваете? )
Все говорят, что они такие же как Palo Alto, только дешевле ;-)
В общем рынок постепенно наполняется чудесами и заказчикам становится все сложнее прорваться сквозь прессинг маркетинга, где им предлагают самые дешевые, самые быстрые и самые качественные устройства все-в-одном. Производителей UTM, которые говорят, что они NGFW уже более 10. Слышу такую фразу: "Мы такие же как Palo Alto, только дешевле". А как проверить это завяление?
Настоящие критерии выбора NGFW
Чтобы "помочь понять продукт лучше" у некоторых производителей datasheet выглядит как набор 20 различных параметров производительности одного и того же устройства в разных режимах и с разными функциями в одном документе. Если сначала все было понятно и была одна скорость (и должна быть сейчас), где измерялась производительность в режиме все включено (помечается как Threat Prevention), то теперь в datasheet черт ногу сломит. Но и даже к этому значению теперь есть вопросы - в каком режиме работы, с какими сигнатурами и на каком трафике было измерено? А какое значение будет на реальном трафике и с нужным реально режимом работы?
Посмотрим на лучшие ресурсы сегодня, где помогают разобраться в NGFW:
✓Проект Anti-Malware провел сравнение различных производителей по функционалу:
✓Видеозапись выступлений производителей по выбору высокопроизводительного NGFW с участием тестовой лаборатории bi.zone и Anti-Malware, Check Point, Palo Alto Networks, UserGate и Код Безопасности
✓Подкаст Netwell "Вежливый безопасник", где мы обсудили результаты тестов NSS Labs NGFW и разбирались почему они отличаются от официальных datasheet. Там есть даже призы за конкурс по "datasheet" )
Поскольку во всех этих статьях и вебинарах описаны присутствующие на нашем рынке производители, то я приглашаю делиться своими впечатлениями о различных производителях в комментах и в телеграмм-канале https://t.me/ngfw_russia
Очень часто при тестировании SSL Decrypt на скорость упускается процесс проверки сертификата. То есть в тесте просто выключают это. А на самом деле включение проверок CRL и использование OCSP серьезно замедляет работу SSL и в том числе SSL Decrypt, поскольку там работа с SSL производится два раза: NGFW работает и как сервер для внутреннего клиента и как клиент для внешнего сервера и оба раза клиенты выполняют проверку сертификата сервера. Так работает любой SSL Proxy.
Вот посмотрите, в сети где одна рабочая станция - запросы OCSP посылает и сам NGFW (модель PA-220) и сама рабочая станция (мой ноутбук). Представляете сколько таких запросов, в сетях где 1000 рабочих станций? Насколько сильно это снижает время установления соединения SSL через SSL Proxy? Надо считать...
Продолжая тему нюансов SSL, в данной статье я расскажу как автоматически исключать сервера, запрещающие вклинивание в SSL сессию, из политики расшифрования. Чтобы автоматически добавлять новые исключения SSL, я использовал механизм auto-tagging.
Что нужно сделать 1. Создать динамическую группу адресов, этот функционал называется Dynamic Address Group (DAG).
2. Стартовать процесс тегирования каждого IP адреса сервера: этот функционал автоматизации находится в Log Forwarding Profile. И эти IP станут автоматически попадать в этот DAG.
3. Создать правило исключения из расшифрования всех адресов из этого DAG.
Как правильно говорить SSL или TLS?
Название протокола SSL придумала фирма Netscape для описания шифрования данных идущих из внешних серверов. Термин SSL был изменен на TLS для того, чтобы подчеркнуть открытый характер стандарта, благодаря чему кто угодно мог использовать его в своих проектах, и тем самым отделить его от фирменного продукта компании. Кроме того, протокол TLS разрабатывался как протокол, независимый от приложений, тогда как SSL изначально планировалось использовать только для подключений HTTP. Оба термина правильные. SSL термин прижился и используется чаще всего, хотя технологически уже давно в сетях это протокол TLS. Также как слово ксерокс прижилось и используется до сих пор, хотя копировать документы научилась не только компания Xerox. Буду использовать далее SSL, понимая, что это все семейство протоколов всех версий SSL и TLS.
Какие приложения используют SSL?
Внутри SSL может быть нетолько HTTP трафик, а SMTP, POP3 или FTP, и другие, там передаются любые данные, нужные приложениям: мессенджерам, обновлениям, базам данных, видеоконференциям. Браузеры используют две версии HTTP/1 и HTTP/2 - они серьезно отличаются друг от друга и их нужно по-разному обрабатывать в средствах защиты. Если мы говорим про вскрытие SSL, то важно наличие движка определения и разбора приложений. Если кто-то говорит, что L4 firewall может вскрывать SSL и что-то там видеть, то это от незнания, что SSL используется разными приложениями. Сейчас уже несколько тысяч различных приложений используют SSL на 443 порту и их надо уметь различать, чтобы защищать компанию от угроз. Если ваше устройство вскрывает SSL на 443 порту и ожидает там HTTP/1, а тамHTTP/2или FTP, то оно просто разрушит работу приложения или не сможет его проанализировать.
Постановка задачи и в чем проблема с расшифрованием SSL
Реализация SSL Decrypt выглядит как хакерская атака категории Man In The Middle (MITM), то есть производится подмену настоящих ключей шифрования и сертификата сервера. Когда вы включаете расшифрование трафика SSL в своей сети, то вы обнаружите, что далеко не все серверы согласны на такое жесткое вмешательство в SSL сессию. Приложения перестают работать, когда вы пытаетесь делать для них атаку "человек посередине" (MITM). И это единственный способ "вскрыть" SSL трафик между клиентом и сервером и получить открытый трафик и отправить на анализ в application control, антивирус, IPS, URL фильтр, Threat Intelligence, DLP и песочницу и другие движки анализа угроз.
Поэтому в каждом устройстве нужно вести список серверов, которые против и отключать функции расшифрования SSL для всех таких сервисов. Что это за сервера: почти все мессенджеры, например, whatsapp, все обновления, например, Microsoft Update, все вебинары, например, gotomeeting и почти все обновления у программ и так далее.
Список сервисов, которые нужно исключать из расшифрования SSL, чтобы они не ломались, уже заложен в NGFW Palo Alto Networks, и выглядит так:
Однако, ведение этого списка - это очень непростое занятие: сотрудников много, сервисов, которые защищают себя от расшифрования все больше. Да, часть сервисов уже добавлены в исключения, но, их больше и постоянно появляются новые.
Как автоматически исключать сервера SSL, с которыми не работает расшифрование? Нужно вести свой список таких серверов. Этими списками URL, IP и DNS можно обмениваться используя механизм внешних список EDL.
Подробнее мы рассказывали в этом видео:
Dynamic Address Group (DAG)
В наших сетях постоянно возникают и исчезают различные новые объекты и одновременно меняются свойства старых объектов: система виртуализации может сама запускать новые веб сервера, старые сервисы могут начать работать ошибочно, сотрудники могут вдруг заразиться и нам нужно вовремя их поместить в карантин. Изменения среды происходит круглосуточно и менять правила доступа межсетевого экрана нужно круглосуточно. Если у вас есть круглосуточная дежурная смена или даже Security Operation Center, то это выполнимо. Но сейчас век автоматизации. Чтобы межсетевой экран сам автоматически менял правила в зависимости от каких-то событий в сети, используйте объект Dynamic Address Group или Dynamic User Groups. Его плюсом является то, что он пополняется объектами без необходимости сохранения конфигурации (не нужно делать commit). Это отличает DGA от обычных статических групп объектов.
В данный объект попадают IP адреса, которые обладают каким-то свойством. Это свойство может пропадать или появляться у IP адреса и соответственно IP адрес то попадает, то исчезает из этого динамического объекта. Чтобы описать новое свойство, мы приписываем IP адресу специальный тег. У каждого IP адреса может быть до 32 тегов (свойств).
Второй пример. Если мы обнаруживаем, что в сети появился компьютер, который начал подключаться к бот-сети, то очевидно, что он заражен. Чтобы остановить распространение вредоносного кода, мы блокируем доступ этому сотруднику к сети, оповещаем его, что ему требуется вылечить свой компьютер для дальнейшей работы в сети компании. Это также может быть и домашний компьютер сотрудника, который подключился в сети по VPN.
Кстати, в этом примере показано не только как IP адресу назначается новый тег, но и как тег убирать после того как сотрудник вылечил компьютер, используя реакцию override в профиле URL.
Я использовал на межсетевом экране политику для выключения расшифрования SSL, используя объект DAG и сейчас про это расскажу.
Попытка расшифровывать трафик с Яндекс.Станции
В моем случае испытуемым объектом является Яндекс.Станция (Алиса). По сути это яркий представитель Интернета Вещей (IoT). Я попробовал включить расшифрование SSL для соединений, которые делает Яндекс.Станция. И обнаружил, что она просто перестает работать. Поскольку Алиса делает очень много подключений по SSL, и против расшифрования, то мне надо было добавить ее в исключения. И мне было интересно, все ли SSL соединения мне надо исключать или часть из них я смогу расшифровать.
Как работает расшифрование.
Когда Алиса подключается к своему серверу, то NGFW перехватывает соединение и начинает работать как прокси-сервер для SSL. И этот режим таки называется: forward proxy.
NGFW подключается к серверу Яндекса, получает от него сертификат и проверяет его подпись, то есть проверяет можно ли ему доверять.
Для самой Алисы NGFW отдает свой сертификат (я его сгенерировал и сделал самоподписанным), говоря что он Яндекс и подписывает это встроенным своим сертификатом. Поскольку Алиса тоже проверяет сертификат, а доверия самоподписанному сертификату от NGFW нет, то она отказывается работать. Так работает много приложений и это справедливо.
Поскольку загрузить свой сертификат в Алису у меня нет возможности, то доверять сертификату она не будет никогда. Нужно добавлять в исключения. Как это добавить вручную показано в видеролике ниже:
Как автоматизировать добавление исключений для SSL
1. Сначала нужно создать тег, который мы будем привязывать к IP адресу.
Заходим в Objects->Tags-Add
Name: SSL-Bypass (любой текст несущий какой-то смысл для вас)
Color: Lime (любой цвет, который вам нравится)
Comments: (любой текст, который вы хотите написать, чтобы потом вспомнить зачем вы завели этот тег)
2. Создадим сам объект. Зайдем в Objects->Address Groups и создадим динамический объект.
Name: Tagged2Bypass (любое имя удобное для вас)
Description: Любой понятный текст
Type: Dynamic
Match: ‘SSL-Bypas’ - можно вбить руками, можно использовать кнопку Add Match Criteria.
Слева появился список всех доступных тегов. В это поле можно вписать логические операции «И» или «ИЛИ», чтобы добавлять только IP адреса, которые соответствую сразу всем перечисленным тегам одновременно (операция И) или хотя бы одному из них (операция ИЛИ)
Мы создали объект Tagged2Bypass, и теперь все IP адреса с тегом SSL-Bypass будут автоматически в этом объекте.
Нам осталось разобраться как же добавлять теги автоматически, в случае ошибки расшифрования SSL. И тут мы будем использовать еще одну функцию межсетевого экрана: автоматическое тегирование.
Log Forwarding Profile и auto-tagging
И это самое сложное и одновременно самое интересное место повествования.
Посмотрите на журнал трафика на скриншоте ниже. Посмотрите в колонку Session End Reason. В журнале трафика каждая запись содержит причину, по которой L4 сессия или сессия приложения L7 была завершена. Если в журнале событий появляется событие связанное с ошибкой SSL, то это значит, что клиент не смог подключиться к своему SSL серверу. Посмотрите на скриншоте: это ошибки decrypt-error, decrypt-cert-validation, decrypt-unsupport-param.
По-хорошему, в любой компании надо заводить кейс под каждую таку строчку, разбираться с ошибкой, но у меня не стоит такой задачи. Пусть эти ошибки будут критерием для добавления в исключение SSL.
Чтобы сервис доступа по SSL заработал, мне нужно автоматически выключить расшифрование SSL для данного Destination IP. И это адрес тоже указан в этой же записи журнала.
На межсетевом экране Palo Alto Networks есть сервис автоматического реагирования на события. Правила реагирования находятся в разделе Objects->Log Forwarding и называются Log Forwarding Profile. Суть каждого профиля в том, что NGFW просматривает каждую новую запись журнала и реагирует на нее: отправляет SNMP, отправляет email, отправляет Syslog в SIEM, ставит тег Source или Destination IP адресу.
Я сделал профиль CheckDecryptErrors.
И в нем сделал одно правило SetTag - на что реагировать и как.
Log Type: traffic (тот журнал в котором есть запись об ошибках SSL)
Filter: (session_end_reason eq decrypt-error) or (session_end_reason eq decrypt-unsupport-param) or (session_end_reason eq decrypt-cert-validation) - это ошибки SSL которые мне нужны, чтобы сделать реакцию
Built-in Action: Tag2Bypass
Я воспользовался кнопкой Filter Builder из интерфейса Log Forwarding Match List, поскольку там была подсказка какие варианты поля Sesson End Reason я могу выбрать. Получилось так: (session_end_reason eq decrypt-error) or (session_end_reason eq decrypt-unsupport-param) or (session_end_reason eq decrypt-cert-validation)
И сразу же можно было посмотреть какие в результате будут выбраны журналы - на что я буду реагировать
Когда NGFW видит ошибку SSL, то он ставит тег SSL-Bypass для Destination IP. В поле Built-in Actions я вписал одно действие для этого.
Name: Tag2Bypass (любое имя с нужным нам смыслом)
Target: Destination Address (мы хотим тег ставить адресу сервера, который отказался работать в режиме SSL Decrypt)
Registration: Local User-ID (за теги отвечает либо NGFW, либо Panorama, в данном случае я хочу чтобы все было локально для этого NGFW)
TimeOut (min): 0 (я хочу чтобы IP адрес был с этим тегом вечно, чтобы я больше не пытался никогда делать расшифрование для этого IP. Лучше ставить время на сутки, потому что таблица тегов не бесконечно и нам не нужно, чтобы она переполнялась.)
Tags: SSL-Bypass (те теги, которые нам нужны для попадания IP адреса в DAG. В данном случае этот тег позволит нам исключить данный IP из расшифрования SSL)
Таким образом данный IP попадает в мой DAG, если случается любая ошибка в SSL.
Не забудьте, что этот Log Forwarding Profile должен быть связан с тем правилом, которое пропускает ваш трафик и соответственно, журналирует его. Имя правила, которое вызывает ошибки мы видели в журнале трафика и мы знаем куда подставлять профиль CheckDecryptErrors. Нам нужно привязать реакцию на ошибку в это правило.
Далее находим это правило в политике безопасности Policies->Security
Кликаем на само это правило и во вкладке Actions добавляем в поле Log Forwarding название нашего профиля CheckDecryptErrors. Теперь, если трафик SSL, который пропущен по этому правилу будет в журнал писать ошибки, то мы автоматически добавим IP адрес сервера в исключения.
Прошу обратить внимание, что само правило написано по порту 443. Я специально написал его как в L4 firewall - без указания приложения L7, поскольку я готовлю другую статью про сравнение L4 и L7 правил. И это правило мне нужно, чтобы показать сколько разных L7 приложений ходит по 443 порту. Как вы видите - за несколько часов, что я потратил на статью в поле Apps Seen есть уже 77 разных приложений.
Видно, что я сделал проверки ошибок SSL не только для Яндекс.Cтанции, но и для всех своих источников трафика в квартире.
Мне останется написать само правило- исключение, которое выключает расшифрование для всех адресов из этого DAG с именем.
Переходим в Policies->Decryption
Перед правилом для соединений Алисы я пишу правило Tagged2Bypass - не делать расшифрование для IP адресов из моего DAG.
Source Address: any
Destination Address: Tagged2Bypass (наш DAG, в который мы добавляем наши IP адреса в случае ошибок SSL)
Service: any (любой порт)
Action: no-decrypt (не надо расшифровывать)
Type: ssl-forward-proxy (режим MITM)
Добавляем правило и делаем Commit.
Итог
Что мы сделали
Создали тег SSL-Bypass
Создали DAG (динамическую группу адресов) Tagged2Bypass
Создали Log Forwarding Profile CheckDecryptErrors
Добавили профиль CheckDecryptErrors в правило по которому идут SSL соединения в разделе Policies - Security
Добавили новое правило BypassDecrypt в Policies - Decryption для выключения расшифрования соединений в сторону адресов из Tagged2Bypass
Сохранили конфигурацию.
Теперь я могу посмотреть сам объект Tagged2Bypass - сколько там IP адресов.
В объекте Tagged2Bypass уже 170 адресов.
В корпоративной сети это сильно помогает, потому что вы автоматически разрешаете ситуацию с блокировкой SSL сессии. Если это не делать автоматически, то вы будете делать это вручную: сервис не будет работать, сотрудник будет создавать кейс, вы будете изучать почему SSL не работает, делать исключения вручную. В данном примере я решил автоматически все 170 кейсов, хотя на самом деле я потратил это время более полезно: написал эту статью.
Компания Okta просмотрела статистику роста числа подключений и лидирующим приложением для конференций стало приложение Zoom, а для удаленного доступа стало приложение GlobalProtect. Компания Palo Alto Networks приняла решение поддержать мир и предложила компаниям использовать бесплатно виртуальные NGFW как VPN шлюзы и также разрешила использовать функционал HIP бесплатно всем заказчикам. Также были выпущены готовые конфигурации VPN в виде шаблонов IronSkillet для NGFW и выпущены подробные инструкции как это настроить. Например, на русском языке.
И еще интересно, что много заказчиков стали пользоваться VPN и NGFW как услугой в рамках сервиса Prisma Access. Подробный рассказ в видеоролике
Также я привел пример реальной интеграции в сеть на основе VLAN Insertion
Как выглядит VLAN Insertion
Про мобильные сети нужно делать отдельный вебинар, успел отметить что есть K2-series firewall для мобильных операторов производительностью 1Тбит/сек.
По традиции расписываю Timeline для быстрого доступа.
Timeline:
0:16 239 приказ ФСТЭК для ЗКИИ не требует сертификации СОВ и МСЭ2:26K2-series firewall для мобильных операторов
3:38 Поддерживаемые функции в K2 firewall
4:33История взлома химического завода через кофе-машину
5:56 Основные проблемы: Shadow IT, поведение пользователей, традиционные средства защиты
7:16 Цифровая трансформация для Industrial Internet of Things (IIoT)
7:41 Статистика по взломам производственных компаний
9:20 Чем отличается безопасность в Information и Operational Technology: фокус, обновления, приоритеты
13:12 Сигнатуры IPS для ICS протоколов
13:50 Статистика NSS Labs по техникам обхода IPS
14:40 Какие приложения видит NGFW: DNP3, IEC 104, ICCP, S7, Modbus, BACnet и другие
17:48 Обзор всей линейки моделей NGFW
18:24 Обзор PA-220R - сертифирован для работы в тяжелых условиях
19:24 Сегментация Zero Trust
20:50 Пример конкретных шагов по реализации безопасности в ICS инфраструктуре
21:35 Список контролей Top 20 Critical Security for Cyber Security
22:46 Инвентаризация - сканируем сеть и рисуем схему
23:50 Мониторинг и визуализация сетевых потоков в SIEM, Panorama, ACC
25:50 Разделение корпоративной сети и DMZ
26:30 Отделение PCN
26:40 Технология VLAN Insertion метод 1
27:50 VLAN Insertion метод 2
29:47 Что настраивать на свитчах
30:27 Что настраивать на NGFW
31:22 Схема к которой мы стремились - маршрутизация плоской сети через NGFW
33:15 Теперь начинаем реализовывать контроли
33:45 Как работать с уязвимостями
35:00 Два подхода: детектировать или блокировать + обновлять или не обновлять
37:15 Burwood Group Lifecycle для цифровой трансформации
39:08 Лучшие методики для защиты IIoT
40:07 Три кита защиты для платформы Palo Alto Networks
40:31 Партнеры Palo Alto Networks
41:12 Siemens, Honeywell, Schlumberger, Accenture, Splunk, Indegy, CyberX, Armis, Nozomi Networks, Security Matters
41:20 XML API для интеграции с партнерскими решениями
42:20 Предлагаем провести workshop по защите ICS и SCADA и сделать SLR отчет
43:35 Выводы
44:45 Gartner, NSS Labs, Forrester Примеры правил для NGFW в SCADA сети
