Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
L7 firewall – это межсетевой экран, который пропускает через себя IP трафик сети и проверяет и заголовки 4 уровня и сегмент данных каждого IP пакета, то есть понимает L7 трафик уровня приложений, вплоть до того какие файлы передаются и в каком направлении
В том же ssh, https и sftp что он видит в сегменте данных то? Хлам? Есть какие-то способы определить что там происходит кроме объёма трафика?
Так-то завернуть vpn в https не особо проблема.
Поэтому в NGFW стоят отдельные процессоры под распознавание приложений L7, под расшифрование SSL/SSH
если бы трафик ssl можно было расшифровать силами одного-двух-сотни процессоров в реальном времени этим протоколом не пользовались бы. Тут не очень понятно.
А всё. Нашел. Оно работает либо если у вас есть закрытые ключи обменивающихся данными, что как-то странно. Либо как банальный MITM что палевно. Никакой магии и расшифровывания ssl нет.
У специалистов в русском языке есть разница в терминах: расшифрование — это когда вы _знаете_ ключ, дешифрование — когда ключ _неизвестен_ и вы взламываете алгоритм криптографический. И вы правы, это не дешифрование, а расшифрование. В английском это один и тот же глагол: decrypt.
Да, вы
— либо расшифровываете методом MITM и тут главное создать trust chain в PKI, например сделать Firewall как Subordinate CA вашего же AD,
— либо грузите закрытый ключ вашего WEB сервера в устройство — и тогда это прозрачно для пользователя.
Вы это видео рекомендую для углубления знаний по SSL/TLS, SSH Decrypt https://www.youtube.com/watch?v=BMiOCJnFBpA
Да, вы
— либо расшифровываете методом MITM и тут главное создать trust chain в PKI, например сделать Firewall как Subordinate CA вашего же AD,
— либо грузите закрытый ключ вашего WEB сервера в устройство — и тогда это прозрачно для пользователя.
Вы это видео рекомендую для углубления знаний по SSL/TLS, SSH Decrypt https://www.youtube.com/watch?v=BMiOCJnFBpA
Хм. Видео с отключёнными оценками и комментариями определённо стоит доверять. Там есть какие-то иные предложения кроме подмены корневых сертификатов или MITM атак?
А. Ок вижу. Действетельно напутал с терминологией. Скучный путь. И как-то, лично мне, сложно считать это повышением уровня безопасности.
А. Ок вижу. Действетельно напутал с терминологией. Скучный путь. И как-то, лично мне, сложно считать это повышением уровня безопасности.
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, все как написано сверху.
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, все как написано сверху.
Уже вышло новое поколение, которое быстрее расшифровывает 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
Вообще это будет описано в третьей части.
У SSL расшифрования есть несколько тонкостей, например, не все сайты и приложения разрешают делать MITM. Поэтому нужно обязательно вести список исключений, вот так он выглядит
https://docs.paloaltonetworks.com/pan-os/8-0/pan-os-admin/decryption/decryption-exclusions/palo-alto-networks-predefined-decryption-exclusions
Вообще это будет описано в третьей части.
Думаю вы сами не забудете уточнить в третей части, но мало-ли. Как сотрудник IT департамента организации владеющей кластером от PaloAlto за не одну сотню кило-баксов, я хотел-бы, в контексте расшифровки SSL, подчеркнуть одну важную деталь:
Это высокотехнологичное оборудование имеет тенденцию раз-другой в год слетать с катушек — сеть рассыпается. Начинается стандартный цирк: звонок в TAC, ескалад, лечение. Причины/объяснения всегда разные и, как по мне, зачастую сомнительные. Суть проблемы не в этом, а в том, что в процессе разрешения «сбоя», TAC с руками и ногами находиться в вашей системе и 'de facto' все ваши приватные ключи перестают быть таковыми.
Уважаемые коллеги должны трезво взвешивать нужна-ли им такая безопасность и такой ценой…
Это высокотехнологичное оборудование имеет тенденцию раз-другой в год слетать с катушек — сеть рассыпается. Начинается стандартный цирк: звонок в TAC, ескалад, лечение. Причины/объяснения всегда разные и, как по мне, зачастую сомнительные. Суть проблемы не в этом, а в том, что в процессе разрешения «сбоя», TAC с руками и ногами находиться в вашей системе и 'de facto' все ваши приватные ключи перестают быть таковыми.
Уважаемые коллеги должны трезво взвешивать нужна-ли им такая безопасность и такой ценой…
мало кто доверяет в форумах «анонимным доброжелателям». Если у вас есть что-то по существу и с фактами, то написать можно в личку, куда я Вам уже написал для сохранения вашей приватности.
По существу хотелось-бы увидеть в третей части нечто вроде: «все новейшие PaloAlto оснащены аппаратными HSM и к приватным ключам не имеет доступа никто», «при общении с TAC, последний никогда не получает доступа к системе клиента и передаваемые диагностические данные всегда вычищены от критичной для безопасности информации». Ну а если такого написать нельзя то можете хотя-бы процитировать меня:
«Суть проблемы не в том что иногда сбоит, а в том что при SSL расшифровке в PaloAlto (и других решениях) оказываются одновременно приватные ключи и посторонние vis-a-vis компании люди. И кстати доступ они получают ведь не только в случае сбоя, а и в случае помощи в настройке всяких плюшек. Я могу еще понять когда приходиться пересоздать новый сертификат для VPN, менять пароли, и т.д. но потенциальная потеря приватного ключа — это инцидент по безопасности.
А теперь представте смену сертификатов для разных сторонних сервисов — IMHO ситуация когда решение хуже проблемы.»
ПС Какие конкретно у нас были и есть проблемы — вопрос частный и по большому счету к делу не относиться. Мне кажется бессмысленным обсуждать тип и частоту проблем и переходить на личности. Проблемы были, есть и будут — такова жизнь: просто некоторые «архитектурные» решения имею серьезные подводные камни.
«Суть проблемы не в том что иногда сбоит, а в том что при SSL расшифровке в PaloAlto (и других решениях) оказываются одновременно приватные ключи и посторонние vis-a-vis компании люди. И кстати доступ они получают ведь не только в случае сбоя, а и в случае помощи в настройке всяких плюшек. Я могу еще понять когда приходиться пересоздать новый сертификат для VPN, менять пароли, и т.д. но потенциальная потеря приватного ключа — это инцидент по безопасности.
А теперь представте смену сертификатов для разных сторонних сервисов — IMHO ситуация когда решение хуже проблемы.»
ПС Какие конкретно у нас были и есть проблемы — вопрос частный и по большому счету к делу не относиться. Мне кажется бессмысленным обсуждать тип и частоту проблем и переходить на личности. Проблемы были, есть и будут — такова жизнь: просто некоторые «архитектурные» решения имею серьезные подводные камни.
Не принимается довод. Извините. Странный вектор угроз. Первый раз слышу, что техподдержка представляет для кого-то угрозу, она, наоборот, вам дается в помощь. Вы все компании, которые вам помогают обвиняете в краже у вас секретных ключей? Или только избранные?
Вы же имеете доступ к секретным ключам своей компании и хвалитесь об этом в Интернет, зачем? Это серьезный инцидент по безопасности. Социальную инженерию тоже никто не отменял. Как другие сотрудники могут вам доверять теперь доступ к секретным ключам?
Вы пожалуйста взвешивайте свои слова, когда пишете обвинения. Вам люди пришли помогать с настройкой — а вы их обвиняете в краже? Супер!
Вы же имеете доступ к секретным ключам своей компании и хвалитесь об этом в Интернет, зачем? Это серьезный инцидент по безопасности. Социальную инженерию тоже никто не отменял. Как другие сотрудники могут вам доверять теперь доступ к секретным ключам?
Вы пожалуйста взвешивайте свои слова, когда пишете обвинения. Вам люди пришли помогать с настройкой — а вы их обвиняете в краже? Супер!
В нормальной ситуации доступ к приватному ключу сертификата сервиса имеет максимум 1-2 админа. Эти 1-2 админа `a priori` обеспечили «Forward Secrecy» для конкретного сервиса и в случае утечки приватного ключа просто перевыпустят сертификат, а старый внесут в CRL своего CA.
В вашем мире вы собираете в одном месте приватные ключи десятков-сотен сервисов. Эти ключи доступны людям управляющим вашим файерволом, не названому количеству сотрудников вендора, а то и вообще половине планеты (если плохо защитили коннект при передаче диагностического дампа) — помним о СОРМ и прочих — недопустимая ситуация.
Мне непонятна ваша «эмоциональность»:
IMHO В идеале приватного ключа сертификата не должно быть ни у кого, но аппаратный HSM дорого и не всегда реализуем.
В вашем мире вы собираете в одном месте приватные ключи десятков-сотен сервисов. Эти ключи доступны людям управляющим вашим файерволом, не названому количеству сотрудников вендора, а то и вообще половине планеты (если плохо защитили коннект при передаче диагностического дампа) — помним о СОРМ и прочих — недопустимая ситуация.
Мне непонятна ваша «эмоциональность»:
Вам люди пришли помогать с настройкой — а вы их обвиняете в краже?При чем тут все это?
IMHO В идеале приватного ключа сертификата не должно быть ни у кого, но аппаратный HSM дорого и не всегда реализуем.
В вашем мире вы собираете в одном месте приватные ключи десятков-сотен сервисов. Эти ключи доступны людям управляющим вашим файерволом, не названому количеству сотрудников вендора, а то и вообще половине планеты (если плохо защитили коннект при передаче диагностического дампа) — помним о СОРМ и прочих — недопустимая ситуация.
Вообще перестал понимать. Ключи доступны половине планеты? Ничесе. Вы можете объяснить как половина планеты крадет ваши ключи и главное зачем этой планете ваши ключи? Почему половина планеты прослушивает ваши диагностические дампы и как она умудряется вытащить секретный ключ из HSM?
Простите но во мне растет уверенность что вы просто не понимаете что такое сертификаты, как они работают и зачем это делается — тревожный симптом. Я отвечу на эти ваши вопросы но далее видимо прекращу этот бессмысленный диалог.
Вы можете объяснить как половина планеты крадет ваши ключиКак я написал «если плохо защитили коннект при передаче диагностического дампа» (mail, ftp, а то и просто слабое шифрование) позволяет любому человеку находящемуся между отправителем и получателем перехватить данные которые в конкретном контексте могут содержать приватные ключи хранящиеся в апплайансе.
и главное зачем этой планете ваши ключи?чтобы делать то что сертификаты призваны не допускать: расшифровка трафика между пользователем и сервисом, создание фальшивых сервисов, и т.д. Если-бы защита была не нужна — ею бы не занимались.
Почему половина планеты управляет вашим файрволом и как она умудряется вытащить секретный ключ из HSM?Не знаю откуда вы это высосали. Перечитайте мой комментарий.
Риски утечки приватного ключа есть. С другой стороны, если взять классический https inspect, то mitm внешний злоумышленник сможет провести, уже преодолев защищаемый периметр. Тут как говорится Тушите свет.
По части американских «партнёров», если их саппорт с руками сидит на периметровой защите, то тут и помимо банальной кражи сертификатов, можно много чего накрутить. Это уже вопрос доверия к вендору.
По части американских «партнёров», если их саппорт с руками сидит на периметровой защите, то тут и помимо банальной кражи сертификатов, можно много чего накрутить. Это уже вопрос доверия к вендору.
Расшифровать не получится. Но! Я работал в компании на 5000 человек с ~15 офисами по миру и я могу сказать, как мы поступали с SSL. Да, Вы абсолютно правы когда сказали, что «Так-то завернуть vpn в https не особо проблема.», но тогда будет видно, что у пользователя огромный поток данных уходит/приходит по SSL и это повод изъять у него комп, а с самим пользователем очень серьезно поговорить. Конечно есть способы балансировки SSL между разными гейтвейями. В целом конечно рано или поздно отловить доброжелателя можно (при условии того, что вы собираете статистику и у вас есть SOC который это всё анализирует), но и как показывает практика — если у человека есть цель подгадить и у него есть техническая экспертиза выше среднего, то остановить его получается не сразу, а иногда не получается вообще. И да: «Никакой магии и расшифровывания ssl нет.» — именно так и именно это иногда очень тяжело донести до ТОПов. В целом L7 FW дают понимание чем люди занимаются на работе и в 99% случаев в компаниях до 200 человек этого более чем достаточно!
Спасибо за развёрнутое объяснение.
Про то, что 'доброжелателей' можно отслеживать по аномалиям в трафике слышал, хотя в живую не разу не щупал.
Просто в статье куча красивостей про анализ HTTP трафика, который в современных реалиях не особо актуален, а лет через 5 дайб-г его станет исчезающе мало. А вот для работы с SSL уже тупо воткнуть файрвол не достаточно. Нужен ещё и пряморукий админ для всего этого дела, который сможет наделать дыр в трафике, не нанеся вреда внешней безопасности либо подключить адекватную аналитику по частоте/объёму.
Про то, что 'доброжелателей' можно отслеживать по аномалиям в трафике слышал, хотя в живую не разу не щупал.
Просто в статье куча красивостей про анализ HTTP трафика, который в современных реалиях не особо актуален, а лет через 5 дайб-г его станет исчезающе мало. А вот для работы с SSL уже тупо воткнуть файрвол не достаточно. Нужен ещё и пряморукий админ для всего этого дела, который сможет наделать дыр в трафике, не нанеся вреда внешней безопасности либо подключить адекватную аналитику по частоте/объёму.
Я знаю, что 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.
Самое сложное, что нас ждет — HTTP 2.0. Вот там будет весело трафик анализировать. Ну и QUIC тоже доставляет удовольствие — его приходится запрещать, чтобы Chrome обратно переходил на SSL/TLS и его можно было расшифровать.
Объясните пожалуйста как в примере с выкладываем файла с секретной презентацией в журнал попало имя пользователя? Я немного не понимаю как из http сессии на роутере вытащить имя пользователя под которым запущена программа которая эту сессию открыла. Или там какое то другое имя пользователя?
Может на компьютерах конечных пользователей должно быть программное обеспечение, которое дополнительно маркирует ip пакеты?
А если бы менеджер выкладывал не саму презентацию, а архив с этой презентацией, попала бы в журнал информация что это поверпоинт и секретно?
Может на компьютерах конечных пользователей должно быть программное обеспечение, которое дополнительно маркирует ip пакеты?
А если бы менеджер выкладывал не саму презентацию, а архив с этой презентацией, попала бы в журнал информация что это поверпоинт и секретно?
по-моему это связано с AD, т.е. файрвол связан с базой.
В NGFW существует механизм идентификации пользователей. Он реализован либо встроенным, либо внешним агентом, буду называть это механизм USER-ID. USER-ID создает и поддерживает таблицу соответствия имени пользователя и его текущего адреса. И бывает, что в таблице есть и значение и порта, если пользователи работают через VDI (то есть пользователи идут с одного адреса источника и их можно различить только по портам).
Перечислю механизмы USER-ID в Palo Alto Networks
Первая — самая часто используемая функция в USER-ID. То есть выполняется периодически чтение сообщений из журналов AD, где записано какой пользователь с какого IP адреса авторизовался, именно из них USER-ID узнает о том по какому адресу пользователь и хранит это внутри NGFW, например для Windows 2008/2012 это сообщения:
Добавил в статью.
Перечислю механизмы USER-ID в Palo Alto Networks
- Server monitoring: User-ID агент читает события Exchange Servers, domain controllers или серверов Novell eDirectory
- Client probing: User-ID агент опрашивает Windows клиентов по WMI
- Terminal services agent: TS агент раздает разным пользователям разные диапазоны TCP/UDP портов для работы с Windows/Citrix Terminal Servers
- Разбор сообщений Syslog: User-ID агент читает syslog соообщения об аутентификации от различных систем, wireless controllers, 802.1x устройств, Apple Open Directory servers, proxy серверов, VPN шлюзов, Сisco ISE
- Аутентификация через клиент GlobalProtect: логин и пароль на VPN + можно добавить MFA
- Аутентификация через через Captive Portal: Web traffic аутентифицируется по NTLM или AAA web формой (Captive Portal используется в Московском метро и кафешках. NTLM позволяет делать аутентификацию прозрачной)
- XML API: информация о входе и выходе передается User-ID агентом специальными командами через REST API firewall
- 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
Добавил в статью.
для фильтрации url от Роскомнадзора Palo Alto не подойдет да? Я там видел ограчение в 100,000 урлов.
Некоторые используют. Судя по копии базы РКН 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 адресов.
Роскомнадзор блокирует и по URL и по IP адресу.
IPшников значительно больше (3699600 на 18 января 2019 судя по usher2.club) и они уже не влезут, поскольку даже в старших моделях ограничение = 150000 IP адресов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Преимущества анализа приложений 7 уровня в межсетевых экранах. Часть 1. Основы