Ну да, а вы хотели найти опен сурс шоб из коробки работал как вам надо и был силвербуллетом? Ну, как грится мечтай в одну руку, сри в другую и смотри какая быстрее заполнится
Хмм, вы канешн меня извините, но статья, которую вы привели в качестве референса, датируется 2005 годом и описывает метод MiTM, где есть явное условие, что PKINIT должен работать в public-key encryption mode. Это уже давно пофиксили + на данный момент имплеметация PKINIT от MS в основном использует Diffie-Hellman mode, ибо perfect forward secrecy и всё такое
PKInit Freshness Extension же был разработан в 2017 году и там упор как раз на митигацию replay атак в Diffie-Hellman mode
Я всё еще не совсем понимаю, каким образом повышая FFL до 2016 левела и, используя PKInit Freshness Extension, мы, в итоге, делаем AD менее безопасной по сравнению с 2012 FFL
Так что за особенности такие, которыми можно злоупетребить, включив PKInit Freshness Extension? Можно какие-то сслыки на PoC, тулы и тд?
Домен заказчика работал на версии 2012 года. Это ограничивало возможности PKINIT, например, мы не могли получить TGT билет Kerberos с помощью сертификата
Либо я чего-то не понял, либо это звучит как бред
Единственное различие между 2012 FFL и 2016 в контексте PKINIT это поддержка PKInit Freshness Extension
Любая попытка в уже существующей инфраструктуре проделать такие штуки, как правило, обречена на провал.
Голубая мечта безопасника - сегментация сети, на границе каждого сегмента стоит ngfw, на который приходит аутентифицированный трафик. Пускаем мы в эту сеть после того, как отработал posture на эндпоинте. Эндпоинт защищён по самые яйца, эталон - PAW.
Красиво звучит, только за всем этим в реальной жизни стоит примерно следующее:
Как правило, нужно очень серьёзно переработать архитектуру сети
Современные файрволы не умеют отличать какой процесс в каком контексте инициировал коннект. Максимум что будет - это таблица UserID, как у F5. Вроде бы есть у фортигадов концепция с агентами, которые в это умеют, но агент это просто ПО, со всеми вытекающими.
Стоимость всего этого добра даже просто на оборудование - космическая. Я уже не говорю про то, что нужны люди.
В основе хорошего Zero Trust лежит современный IdP. Практически во всем тырпрайзе есть AD, которое не заточено под эту концепцию. Вы не задумывались, почему все практические реализации этого нулевого доступа - облачные? С EvoSTS в Azure ты можешь идти смелой дорогой в zero trust, с AD уже не так все радужно.
В РФ ситуация осложняется тем, что у основных вендоров, кто в это умеет, нет своего ДЦ, а значит надо принять соответствующие риски.
В общем, тема интересная, дискуссионная, но искусственно раздутая, как по мне.
У вас ссылка на authN Policies, это немного про другое. Точнее, совсем про другое. Это про то, что к определённым политикой сервисам контроллер выдаёт tgs определённому пулу security principals.
Наверное, вы имели ввиду вот это про словари и пароли.
Если вы предполагаете ответ "люди", то у меня для вас плохие новости
Ага, верим :)
Ну да, а вы хотели найти опен сурс шоб из коробки работал как вам надо и был силвербуллетом? Ну, как грится мечтай в одну руку, сри в другую и смотри какая быстрее заполнится
Но может им стать при должной упоротости
Думаю, пора менять password management на passwordless, красота названия концепции не пострадает
А, ну то есть вы настроили клиента oidc из коробки и решили написать по этому поводу пост на хабре?
Штош...
Расскажи это phishing resistant MFA
Всё зависит от конкретных реализаций в конкретных продуктах
Блин, я понимаю, праздник, все дела, но шо ж так жирно то накидывать на вентилятор?
Хмм, вы канешн меня извините, но статья, которую вы привели в качестве референса, датируется 2005 годом и описывает метод MiTM, где есть явное условие, что PKINIT должен работать в public-key encryption mode. Это уже давно пофиксили + на данный момент имплеметация PKINIT от MS в основном использует Diffie-Hellman mode, ибо perfect forward secrecy и всё такое
PKInit Freshness Extension же был разработан в 2017 году и там упор как раз на митигацию replay атак в Diffie-Hellman mode
Я всё еще не совсем понимаю, каким образом повышая FFL до 2016 левела и, используя PKInit Freshness Extension, мы, в итоге, делаем AD менее безопасной по сравнению с 2012 FFL
Так что за особенности такие, которыми можно злоупетребить, включив PKInit Freshness Extension? Можно какие-то сслыки на PoC, тулы и тд?
Либо я чего-то не понял, либо это звучит как бред
Единственное различие между 2012 FFL и 2016 в контексте PKINIT это поддержка PKInit Freshness Extension
Объясните, что имели ввиду?
Zero Trust - это buzzword.
Любая попытка в уже существующей инфраструктуре проделать такие штуки, как правило, обречена на провал.
Голубая мечта безопасника - сегментация сети, на границе каждого сегмента стоит ngfw, на который приходит аутентифицированный трафик. Пускаем мы в эту сеть после того, как отработал posture на эндпоинте. Эндпоинт защищён по самые яйца, эталон - PAW.
Красиво звучит, только за всем этим в реальной жизни стоит примерно следующее:
Как правило, нужно очень серьёзно переработать архитектуру сети
Современные файрволы не умеют отличать какой процесс в каком контексте инициировал коннект. Максимум что будет - это таблица UserID, как у F5. Вроде бы есть у фортигадов концепция с агентами, которые в это умеют, но агент это просто ПО, со всеми вытекающими.
Стоимость всего этого добра даже просто на оборудование - космическая. Я уже не говорю про то, что нужны люди.
В основе хорошего Zero Trust лежит современный IdP. Практически во всем тырпрайзе есть AD, которое не заточено под эту концепцию. Вы не задумывались, почему все практические реализации этого нулевого доступа - облачные? С EvoSTS в Azure ты можешь идти смелой дорогой в zero trust, с AD уже не так все радужно.
В РФ ситуация осложняется тем, что у основных вендоров, кто в это умеет, нет своего ДЦ, а значит надо принять соответствующие риски.
В общем, тема интересная, дискуссионная, но искусственно раздутая, как по мне.
Работать надо, а не про zero trust мечтать (с)
Например, подобную систему использует Microsoft.
У вас ссылка на authN Policies, это немного про другое. Точнее, совсем про другое. Это про то, что к определённым политикой сервисам контроллер выдаёт tgs определённому пулу security principals.
Наверное, вы имели ввиду вот это про словари и пароли.