В шахматах есть понятие "детский мат", когда неопытный игрок проигрывает партию за 3 своих хода.
В корпоративных сетях ситуация сложилась такая же - очень много инсталляций VPN шлюзов сделано так, что любой хакер проникает внутрь сети за один шаг.
Основные три ошибки детского VPN:
Логин и пароль единственное, что нужно знать для проникновения в сеть.
Рабочая станция дома никак не защищается и любой хакер попавший на компьютер мгновенно узнает логин и пароль на VPN и следующим шагом попадает в сеть компании с полными правами данного сотрудника.
Сетевое подключение внутри сети никак не защищается и любой сотрудник компании может делать все что угодно: забирать файлы, оставлять файлы, копировать информацию компании или уничтожать.
Такой VPN называется тоже детским. Обычно это значит, что автор этой дыры в безопасности просто прочитал документацию к каком-то шлюзу, например, это часто OpenVPN и собственно реализовал этот дырявый VPN для своей компании. Да, решение ставится методом next-next-finish, но дает доступ не только сотрудникам, он и всем-всем-всем.
Взрослый VPN: MFA, HIP, NGFW
Соответственно, исправление ситуации достигается изменением и повышением безопасности всех трех ошибочных пунктов.
1. MFA. Двухфакторная аутентификация
Кража и подбор логина и пароля является частой атакой и применяется постоянно. Чтобы минимизировать эту угрозу нужно использовать второй фактор. В современных VPN существует компонент, который позволяет добавить проверку сообщения на телефоне, и это рекомендуется делать. Лидером игроками здесь является компания Okta, но я приведу весь квадрат Gartner где показаны другие проекты позволяющие реализовать второй фактор. Есть еще одна частая ошибка - сертификат считают вторым фактором. Однако он хранится на компьютере жертвы и его нельзя считать за второй фактор. Второй фактор должен быть обязательно на стороннем устройстве.
2. HIP и XDR. Comliance проверки.
Рабочая станция дома - это точка наивысшей опасности. То что мы дали сегодня людям возможность подключаться не с рабочих машин, а с домашних компьютеров - в общем уже большая дыра в безопасности. А то что мы еще и не контролируем ничего там - это просто epic fail. Но главное не бояться! Все поправимо
Существуют реально два механизма, которые могут нам помочь дома
проверка состояния хоста клииентом VPN
проверка состояния хоста специализированной защитой EDR/XDR
Host Information Profile позволяет шлюзу VPN убедиться, что вы подключаетесь с рабочей станции, на которой выполнены минимальные проверки безопасности. Для вас этот фукнционал может быть неожиданностью, однако это стандартные функции корпоративного VPN, который предоставляют такие лидеры рынка VPN как Palo Alto Networks.
EDR/XDR позволяет постоянно контролировать что происходит на рабочей станции, блокировать угрозы и расследовать инциденты, если требуется.
Если вы будете проверять обоими методиками, то вы создадите серьезные проблемы злоумышленнику. Начните!
3. NGFW
Сам VPN клиент архитектурно может приземлять ваши IPSEC туннели в сеть и сразу давать доступы к нужным ресурсам: серверам, рабочим станциям. Однако это неверно с точки зрения безопасности - архитекторы приземляют VPN сегодня в NGFW. NGFW это многофункциональное устройство и оно не просто дает вам доступ в сеть как VPN шлюз, но и контролирует домашнего пользователя: что он делает, каким приложением, какие файлы забирает, нет ли там вирусов или не производит ли он сканирование сети. Если вы не используете NGFW для контроля действий сотрудников, которые подключены по VPN, то любой человек делает в сети что ему заблагорассудится, а если это хакер, то он вам всемерно благодарен.
По идее все эти три пункта сделать несложно, но нужно постоянно контролировать изменения, ведь у вас меняются люди, меняется архитектура подключений.
И еще тонкость
И в заключение важно заметить, что удаленный доступ выявил одну проблему: никто никогда не планировал в компаниях доступы сотрудников. Часто все доступно всем. В случае с удаленным доступом из дома это создало катастрофический объем возможностей для злоупотреблений. В случае, когда люди работали из офиса, то это было незаметно, а вот сейчас, когда человек из дома имеет ко всему, причем ненужному ему по работе - это то, что нужно минимизировать. Обсудите этот проект в своей компании и займитесь минимизацией привилегий. И это срочно!
В стандарте Центрального Банка ГОСТ 57580 существует несколько пунктов, где упоминается межсетевое экранирование на прикладном уровне, например, в разделе 7.3. ЦБ говорит, что с 1 января 2021 года эти требования УЖЕ должны быть выполнены для банков России. Но проблема в том, что у многих банков стоят устаревшие межсетевые экраны, в которых включение анализа трафика на уровне приложений просто невозможно - у них не хватает производительности. Продвинутые банки делали весь этот год проекты по замене межсетевых экранов на более производительные. Хитрые банки сделали проще - они просто выключили все функции анализа и с выключенной функциональностью межсетевые экраны тянут нужные скорости. Но с 1 января эти банки так сделать не смогут - нужно будет показывать свои настройки во время аудита и возникнет вопрос как быть - ведь сеть просто упадет при включении любой дополнительной функции: анализ приложений и файлов в них - это очень нагрузочная операция для процессора любого устройства.
Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Одной из областей, которой часто не уделяется должного внимания, является DNS. Контролируете ли вы свой DNS трафик?
Серьезность проблемы в том, что по данным Palo Alto Networks Unit 42 Threat Research, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.
Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.
При правильной настройке 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).
Во-вторых, создайте правило для трафика приложения «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).
Раньше я думал, что это шутка: рубильник для выключения Интернет, стоп-кран в самолете и так далее, но чем дольше я живу, тем все больше мир поражает меня...
Был шуточный репортаж, где делали Internet Kill Switch в шутку:
Однако, сегодня прочитал в блоге у Алексея Комарова что нет! Наши стартапы могут все: на полном серьезе это сделано и нас и продается по цене 10000 рублей )
Смотрим и внимаем )
У меня даже нет слов... кулачковый переключатель! рвет все 8 физических линий! защищен от окисления! делали нагрузочное тестирование! техподдержка интересно продается? )
И цена!
И даже есть процесс применения! Система автоматизации SOAR отдыхает )
АСУТП защищен )
И, кстати, это не единственный такой реальный агрегат. Есть еще в том же стиле "размыкатель Ethernet", но он сделан для противодействия угрозе снятия информации с кабеля через анализ электромагнитных излучений, что кратко именуется ПЭМИН.
И это еще не все! Мир пошел дальше и есть даже физические переключатели между двух разных сетей Ethernet:
Все это сейчас активно обсуждается на Яплакал и Pikabu
Современная безопасность ушла далеко вперед, если раньше мы слушали курс по IPS в течении недели, то теперь IPS - это десятая часть функционала устройства под названием NGFW. Есть ли у нас десять недель, чтобы освоить NGFW? Обычно нет. Но и их мало, реально нужно год - два, чтобы освоить эти устройства.
Есть три компонента у всех NGFW: приложения, пользователи и защита. У Palo Alto Networks это App-ID, User-ID и Content-ID. Если один раз разобраться что эти функции все делают, то складывается понимание всех NGFW и тогда ты уже понимаешь на новом уровне что можешь сделать со своим трафиком. Есть набор видеороликов обучающих на сайте https://panacademia.ru/webinars/
Лучше всего посмотреть вот эти три, где все знания сконцентрированы.
Люди случайно попадают на копии сайтов: интернет-магазинов, банков и др. через поиск или через контекстную рекламу. Вы ищете магазин, допустим Леруа Мерлен, но не знаете как правильно пишется их сайт по-французски, делаете ошибки и опечатки и находите какой-то сайт, и потом выясняете, что это просто компания, которая доставляет вам товары из этого магазина, но не сам магазин. Или еще хуже - это поддельный сайт, где оплатить товар можно, но получить его и деньги - никогда. Сайт, на который вы зашли может быть прокси-сайтом, то есть он показывает вам экран известного интернет магазина и одновременно данные которые вы туда вводите: ваш логин/пароль и номер карты. Часто это работает на том, что вы не смотрите на иконку рядом с названием сайта, а там должен быть "замочек", и не смотрите на само название сайта: используются похожие начертания, но сайт реально не тот. Вот такой замочек, например, у моего блога:
Если вы попали на копию, то даже профессионалам порой бывает сложно отличить настоящий сайт от поддельного. Стали применять интересную технологию: сайт работает по HTTP, а не по HTTPS - и если вы невнимательны и не проверяете наличие замочка в URL, то отдаете сайту все свои знания про свои пароли и кредитки.
Сюда также отношу фейковые приложения в телефоне. Нужно смотреть рейтинг и сколько людей уже поставило это приложение. Если приложение под названием Belka поставило всего 100 человек, то стоит задуматься то ли это приложение, которое вы хотели поставить.
Зачем это?
Украсть ваши деньги.
Украсть ваш пароль и требовать выкуп.
Как защищаться домашним пользователям?
Встроенная защита от фишинга в браузеры уже есть у всех поставщиков: Chrome, Firefox, Edge, Safari. Проверьте что соответствующая галочка включена в разделе Безопасность.
Вы должны ожидать, что защита будет блокировать сразу вредоносный URL - встроенные средства защиты от фишинга в браузер пользуются базой таких сайтов.
Google Chrome молодец - он проверяет также ваши логины/пароли по базе украденных паролей. Они собирают все публично выложенные пароли и когда вы вводите свой пароль - смотрят, нет ли его в базе украденных. Если ваш пароль украли - смените его!
Новые сайты - это угроза похуже. Их еще нет в базах. И что делать? Начать с того, что сайт работает по HTTPS и он с правильным сертификатом. Тот самый "замочек" перед названием сайта. Однако существуют бесплатные сертификаты, например, Let's encrypt и хакеры обычно ими пользуются.
Вас могут защищать дополнительные плагины к браузеру - они проверяют репутацию сайта и показывают ее вам. Например, если используется Let's encrypt, то это должно настораживать и это сразу снижает репутацию сайта. Например, есть расширение Netcraft.
Пользоваться двухфакторной аутентификацией! Если instagram, facebook и другие сайты уже сделали это - включите! Если какой-то сайт не сделал - требуйте. Поскольку это также защищает от фишинга.
Еще нужно проверять по категориям и блокировать неизвестные еще, но это может только NGFW которые есть только в корпоративных сетях. Однако сейчас распространены сервисы класса SASE или SWG - защита из облакака. Вы можете пользовать ними - там есть в том числе URL фильтрация по категориям. Но они также требуют настройки.
Вы можете у вас дома пользоваться внешним защищенным DNS, например, Яндекс DNS. У него есть информация по вредоносным адресам DNS и он подменяет ответы к таким сайтам на страницу заглушку, чтобы оберечь вас от заражения или кражи данных.
И еще совет: заносите свои сайты, где вы тратите деньги в закладки, чтобы не искать их и не кликать на ссылки в контекстной рекламе.
Как защищаться компаниям?
Все то же самое что и домашние пользователи, например, использовать встроенную защиту от фишинга в браузере. Попросите свою техподдержку это включить. Также проверку ваших паролей по базе украденных и дополнительные плагины и возможно также менеджер паролей.
Поскольку у безопасника компании есть еще одна задача: защищать не просто своих сотрудников, а еще и клиентов своей компании, например, которые пользуются приложениями компании, то нужно еще проверять приложения в Google Play и Apple Store, чтобы там не появлялись фейки.
Если вы пишете приложение для компании, то лучше использовать взаимную аутентификацию: не только клиент проверяет что сервер тот самый, но и сервер проверяет, что приложение то самое.
Использовать двухфакторную аутентификацию - здесь много уже готовых средств в корпоративной сети, но также ваши NGFW могут добавлять второй фактор поверх любого приложения.
Есть программы, которые находят копии сайта вашей компании. Их надо запускать периодически и оповещать свою службу ИБ о находках.
Есть также утилиты, которые могут проверять создание похожих доменов. Это нужно делать постоянно.
Грамотное решение защиты своих клиентов: Аватар. Например, так сделано на портале gosuslugi.ru. Когда хакер делает поддельный сайт, то он не может скопировать ваш аватар, и поэтому когда вы заходите на подделку, то вы свой аватар там не найдете и это уже является сигналом, что что-то идет не так.
В компании нужно использовать NGFW, в котором встроены механизмы блокировки фишинга по URL категориям. В Palo Alto Networks NGFW недавно встроили Machine Learning, который позволяет определять новые фишинговые сайты и даже zero-day файлы на лету.
Также в NGFW есть проверка ввода паролей и логинов домена - то есть, когда вы пытаетесь ввесть логин и пароль от своего домена на стороннем сайте (поддельном), то NGFW это предотвратит или оповестит.
Что вообще может проверять компания: какие типы файлов хочет скачать человек, какие URL хочет посетить, какие DNS адреса запрашивает. Все это защищается.
Также VPN клиенты позволяют подключить домашний компьютер сотрудника к корпоративному NGFW в котором есть все методики защиты. Или сейчас весь мир переходит к облачному сервису защиты, Gartner называет этот сервис SASE. Но это отдельный разговор.
Также рекомендуется запустить программу рассылки тестовых фишинговый писем, например, компания Антифишинг предлагает это.
Тест
В завершение проверьте свои навыки защиты от фишинга
Когда вы хотите купить NGFW, то нужно что-то написать в офис производителя, чтобы он подобрал вам модель.
Что нужно прислать в заявке:
1. Планируемый максимальный защищаемый объем трафика в секунду. (Если NGFW будет защищать периметр или ЦОД, то посмотрите вашу максимальную скорость трафика на периметре или в ЦОД во всех направлениях: входящий + исходящий на всех интерфейсах.) Например: хотим NGFW для защиты трафика на скоростях в пике до 10 Гбит/с.
2. Число хостов в сети, которые генерируют трафик. (На самом деле инженеру для оценки нужно число новых соединений в секунду. Опыт показывает, что каждый хост создает в среднем 0,1 новых соединения в секунду. Но лучше взять с запасом по соединению на каждый хост в секунду. То есть для 10000 хостов число новых соединений в секунду будет 10000.) Пример запроса: у нас 10000 хостов в сети (посчитайте все сервера, компьютеры, роутеры, принтеры и другой IoT)
3. Если есть публичные ресурсы к которым ходит весь Интернет, то сколько новых соединений в секунду в пике бывает на эти ресурсы (если получится это оценить). Слово новых - ключевое. Не путайте число новых соединений с числом одновременных соединений. Обычно это можно посмотреть на графике системы мониторинга, которая обычно у всех есть. Завышать не нужно, потому что сам сервер может не выдержать число новых соединений в секунду, которые вы запросили. Обычно еще стоит WAF или DDOS, который как раз режет число новых соединений, и на самом деле NGFW тоже содержит функции сдерживания числа новых соединений в секунду. (Если у вас есть F5 или A10 или еще какие-то балансировщики - это тоже надо упомянуть. Но это отдельный разговор.) Пример: Число новых соединений в секунду в пике на наши веб сервера: 1000 HTTP(S) соединений в секунду.
4. Нужна ли подписка Threat Prevention, которая включит обновления антивируса, IPS, anti-spyware, TI, DNS Sinkholing. У некоторых производителей подписка anti-spyware называется anti-bot.
5. Нужна ли подписка URL Filtering. Обычно в ЦОД она не требуется.
6. Нужна ли подписка Wildfire - песочница облачная и также встроенная (у Palo Alto Networks внутри NGFW есть Machine Learning, который обнаруживает zero day на лету)
7. Нужна ли подписка Global Protect (функционал HIP для удаленных сотрудников, позволяющий пускать только защищенные компьютеры в сеть компании )
8. Нужна ли подписка DNS Security для определения DGA доменов.
9. Нужна ли подписка Autofocus для расследования инцидентов и подключения к TIP.
10. Нужна ли подписка IoT для контроля устройств IoT в вашей сети. Замечу, что контроль ICS/ SCADA уже входит в стандартную поставку.
10. Будет это кластер из 2 устройств или standalone.
11. На сколько лет посчитать подписки и поддержку. Обычно заплатить за 3 года сразу дешевле чем три раза покупать по одному. Пример: Нужны все подписки на 5 лет.
PS: На самом деле инженер производителя в первую очередь оценивает тип вашей компании: финансовая, медиа, телеком, производство, государство и др, потому что это разный трафик и это разная нагрузка на устройство. Например, финансовый трафик содержит более короткие транзакции и поэтому NGFW больше напрягается. Причем модель иногда нужно давать в 2 раза мощнее, чем заказчику с таким же трафиком (по сумме байт в секунду), но с более длинными транзакциями. То есть на трафик 10 Гбит/с для коротких транзакций будет одна модель, на трафик 10 Гбит/с для длинных транзакций - другая. Проблема, что никто не знает своего трафика и длины транзакций уж тем более. Поэтому перед покупкой NGFW его нужно тестировать именно на своем трафике и со всеми включенными функциями. Обычно это можно сделать через SPAN порт вашего свитча, что не прерывает работы компании на время теста.
Основой для выбора будет параметр Threat Prevention Throughput и New Sessions per second. Параметр максимальное число одновременных сессий (Max Session) обычно не влияет, потому что он у всех NGFW поддерживается с большим запасом, даже если измерен с буферами для хранения L7 сессий. Чтобы где-то хостами генерировалось одновременно больше 1 миллиона сессий одновременных - я не видел даже у заказчиков у которых 200000 пользователей.
Как различить куда заходит сотрудник в облаке: в корпоративный аккаунт или в свой личный? С точки зрения межсетевого экрана это один и тот же сайт, например, login.microsoft.com. Но отличие в том, что логин происходит на разные аккаунты. Облачные провайдеры SaaS придумали как ограничить доступ - межсетевой экран должен лишь сказать облаку какие домены разрешены для логина, а какие нет. Допустим вы хотите, чтобы заходили только на ваш домен business.com. И вы должны это сказать облаку. Это делается при помощи специального заголовка HTTP, который называется Restrict-Access-To-Tenants, что описано в документации у Microsoft. Но кто будет добавлять такой заголовок в трафик из вашей сети? Ваш межсетевой экран. В Palo Alto Networks NGFW эта функция называется HTTP Header Insertion. Эта функция работает для различных типов облаков, включая Office365. Подробно описание тут.
Если ваш сотрудник попытается зайти на несанкционированный домен, то сам портал Microsoft выдаст сообщение, что это запрещено.
После того как вы взяли под контроль доступ к порталу возникнет вопрос: великолепно, но к корпоративному аккаунту есть доступ из Интернет, минуя корпоративный firewall. И тут есть хороший вариант: использовать продукт Prisma SaaS, который в облаке контролирует что делает сотрудник и включает DLP, антивирус, песочницу и контроль писем и файлов. Подробнее в видеоролике
Система оркестрации, автоматизации и реагирования (СОАР) все чаще упоминается на встречах и одновременно многие спрашивают что именно другие автоматизировали. Мы собрали самые частые задачки в одну презентацию и показали. На самом деле плейбуков несколько тысяч и вы должны автомтизировать те задачи, которые "устали" делать сами вручную. Это может быть даже не совсем ИБ задача, а немного ИТ, или про финансы, или про операционные контроли.
А вообще SOAR уже не тот ) Надо использовать XSOAR!
Задача написания правил на межсетевом экране непростая, потому что правил много. Я встречал межсетевые экраны, где было 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 кейсов, хотя на самом деле я потратил это время более полезно: написал эту статью.
