'

Путешествие на ракете Kerberos

Понравилась презентация – покажи это...





Слайд 0

Путешествие на ракете Kerberos Билетики, пожалуйста… Станкевич Александр Stanky@stanky.ru


Слайд 1

Kerberos Что это? Active Directory использует Kerberos, когда может Отличается от LM/NTLM/NTLMv2, основан на стандартах RFC 1510 и других Имеет собственный словарь терминов: клиент, сервис, пре-аутентификатор, аутентификатор, учётные данные, ключ сессии, билет, Ticket Granting Ticket, Service Ticket, Key Distribution Center, Authentication Service, Ticket Granting Service


Слайд 2

Kerberos Вид из космоса Упрощённо, это службы, работающие на контроллере домена Понимает две вещи (“Principals”): пользователи и сервисы (такие как файловые службы на сервере) Когда пользователь хочет получить сервис, он запрашивает билет на этот сервис Затем, пользователь предъявляет сервису этот билет, когда хочет им воспользоваться


Слайд 3

Головы Kerberos Kerberos имеет три головы Клиенты или “User Principals”: учётные записи пользователей; каждая имеет свой пароль и имя – “UPN” Сервисы или “Service Principals”: нечто к чему мы хотим получить доступ; это может быть просто сервер или его отдельный сервис (файлы/печать, SQL, Exchange); каждый сервис имеет своё имя – “SPN” и пароль Key Distribution Center (KDC) – контроллер домена, сервер, который знает все пароли пользователей и сервисов. Имеет собственный пароль, известный только ему самому (учётная запись “krbtgt”) и другим контроллерам в домене. Отложим пароли на некоторое время в сторону; а сейчас…


Слайд 4

Kerberos в картинках Встречайте наши головы…


Слайд 5

Kerberos в картинках Для выполнения этого… Это “что-то” называется билет (Ticket); они бывают двух видов


Слайд 6

Kerberos Два вида билетов, две службы Вначале, мы представляем себя KDC, входя в систему; чтоб выполнять вход только один раз, мы просим KDC предоставить “билет на KDC”… и это Ticket Granting Ticket Он предоставляется частью KDC, которая называется “Authentication Service” или AS Получив TGT, мы можем предъявить его KDC и сказать: “Помнишь меня? Теперь мне нужен Service Ticket к такому-то сервису…” Service ticket выдаёт другая часть KDC, которая называется “Ticket Granting Service” или TGS


Слайд 7

Как это размещается в DC? Key Distribution Center = Authentication Service + Ticket Granting Service KDC = AS + TGS KDC, AS, TGS – всего лишь часть ролей, которые выполняет контроллер Тем не менее, мы не можем увидеть AS, TGS и другие службы в Task Manager; они выполняются внутри процесса LSASS


Слайд 8

Kerberos Почему два вида билетов? Ticket Granting Ticket как и Service Ticket аутентифицирует нас сервису Но обычно, всё заканчивается всего одним TGT и множеством ST Причина наличия двух видов билетов: Kerberos защищает каждый билет, шифруя часть его данных с помощью пароля или ключа


Слайд 9

Kerberos Ключевые причины почему Kerberos лучше Множество билетов подразумевает множество шифрования информации с помощью нашего пароля – это значит, что злоумышленник будет иметь множество данных для вычисления пароля Итак – и это очень важный момент – то, что предоставляет Kerberos в TGT, по сути дела, является “паролем на день” Информация, относящаяся к Service ticket, шифруется с помощью этого дневного пароля; только относящаяся к TGT информация шифруется с помощью вашего пароля – одна транзакция в день!


Слайд 10

Kerberos в картинках Сперва, Тому нужен Ticket Granting Ticket


Слайд 11

К слову о Vista и выше Если взглянуть на сетевой трафик, когда Vista пытается выполнить вход, мы увидим, что запрос TGT в первый раз всегда завершается неудачно. Vista сознательно отправляет “плохой” пакет, чтобы определить возможность использования AES вместо RC4-HMAC – возвращаемое сообщение об ошибке “KDC_ERR_PREAUTH_REQUIRED” содержит в себе список возможных алгоритмов


Слайд 12

Итак… Том нажал Ctrl + Alt + Del, ввёл свои имя и пароль и получил TGT Но он всё ещё не вошёл на свой компьютер Ему нужен доступ к его рабочей станции Он получит его с помощью Service Ticket Итак, это следующая вещь, которую ему нужно попросить у Ticket Granting Service


Слайд 13

Kerberos в картинках Далее, Том получает Service Ticket Том предъявляет TGS свой TGT и запрашивает ST на свою рабочую станцию TGS проверяет TGT и создаёт Service Ticket, идентифицирующий Тома службе Workstation, компьютера TOMSPC; затем, Том предъявляет этот билет TOMSPC Теперь Том вошёл на свою рабочую станцию!


Слайд 14

Итак… Том вошёл на свою рабочую станцию Он получил TGT, который использует для запроса Service Ticket у Ticket Granting Service Он получил Service Ticket к своей рабочей станции Эти “билеты”, на самом деле, всего лишь данные в памяти компьютера TOMSPC Том может посмотреть их с помощью kerbtray или klist, входящих в Resource Kit klist теперь встроена в 2008


Слайд 15

Вывод утилиты klist C:\>klist tickets Cached Tickets: (2) Server: krbtgt/STANKY.RU@STANKY.RU KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) End Time: 5/11/2010 22:10:08 Renew Time: 5/18/2010 12:10:08 Server: host/tomspc.stanky.ru@STANKY.RU KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) End Time: 5/11/2010 22:10:08 Renew Time: 5/18/2010 12:10:08


Слайд 16

На принт-сервер… Точно таким же образом, Том может получить билет к службе печати на PS (в klist это отображается, как cifs/ps.stanky.ru…) Он предъявляет TGS свой TGT Контроллер проверяет TGT и выдаёт Тому Service Ticket, идентифицирующий его на PS Теперь у Тома три билета


Слайд 17

Том и его билеты


Слайд 18

Звучит хорошо, но безопасно ли? Время погрузиться в детали Всё это звучит хорошо… Но как мы это обезопасим? Почему злоумышленник не может перехватить билеты, которые говорят “Привет служба печати PS, я Том”? Ключ – это хорошо… Ключи – это следующая часть нашего Марлезонского балета


Слайд 19

Безопасная идентификация Мы хотим иметь возможность идентифицировать друг-друга через небезопасную сеть; мы можем сделать это, если: Договоримся об алгоритме шифрования Договоримся о секретном ключе Договоримся о данных для коммуникации Например: я говорю, что вы можете узнать меня по приветственному сообщению, которое вы расшифровываете DES’ом и 56-ти битным ключом, который знаем только я и вы, и если оно гласит “Текущее время X”, тогда я, действительно, могу безопасно идентифицировать себя перед вами, скажем, через интернет


Слайд 20

Kerberos и AD… Мы договариваемся: Алгоритм шифрования: RC4-HMAC Общий секретный ключ: мы позволяем KDC создать произвольный 128-ми разрядный ключ и передать его только нам Данные распознавания: блок данных, называемый “аутентификатор” Когда “аутентификатор” расшифрован, он должен доказывать другой стороне, что мы знаем общий секретный ключ *Server 2008 позволяет использовать AES (ура)!


Слайд 21

Общие ключи так же полезны… Однажды получив общий ключ, который больше ни кто не знает, клиент и сервер могут выполнять другие вещи, помимо аутентификации, такие как: Подписывание SMB Безопасные (шифрованные) сессии Обмен ключами IPsec для AH или ESP (подписывание или шифрование) Любые другие формы подписывания или шифрования


Слайд 22

Ещё одно требование к ключам Было бы замечательно, если б ключ, который мы используем, не был одним и тем же, каждый раз Вместо этого, при необходимости поговорить, было бы лучше, если б мы каким-то образом договорились о ключе, который бы действовал всего несколько часов и мы бы никогда больше его не использовали – ключ для сессии Такой ключ называется ключом сессии (“Session Key”)


Слайд 23

Предназначение Kerberos Как получить ключ без его перехвата? Мы договорились о содержимом аутентификатора, который мы шифруем, используя согласованный алгоритм Всё, что нам нужно: Сервер, генерирующий произвольные ключи сессий, которые используются всего несколько часов Метод, позволяющий передать вам и мне эти ключи без перехвата Это и делает Kerberos. Периодически.


Слайд 24

Выдача ключей – часть I: Ключ сессии в Ticket Granting Ticket Помните билеты – сперва TGT, потом Service Ticket? Теперь рассмотрим часть ключей Когда Том просит TGT у AS, он, в действительности, просит две вещи: TGT, который он предъявляет TGS, когда ему нужен Service Ticket и Специальный ключ сессии “только на сегодня”, известный только Тому и KDC Вот как это работает (уже подробней, но всё ещё немного упрощённо)


Слайд 25

Поехали… “Сейчас 12:10, 11 Мая 2010” Том создаёт штамп времени Затем он отправляет “пре-аутентификатор” на AS Шифрует используя “NT hash”, хэш MD4 Unicode-версии его пароля


Слайд 26

AS создаёт ключ сессии AS расшифровывает временной штамп, используя хэш пароля Тома; время находится в пределах пяти минут от текущего, поэтому AS верит, что это Том. Отправляет результаты Тому


Слайд 27

Том получает TGT и ключ сессии Том не может расшифровать TGT, но он может расшифровать копию “сегодняшнего ключа” сессии Tom-KDC Теперь только Том и KDC имеют копии ключа Tom-KDC, и ни кто не “прослушал” их общение.


Слайд 28

Чего мы этим достигли? Во-первых – получили общий ключ сессии (“на сегодня”) между KDC и Томом Во-вторых – получили структуру данных (TGT), которую может расшифровать только KDC Так как только KDC мог создать TGT, и TGT содержит “сегодняшний ключ” Tom-KDC, Том может предъявить TGT всякий раз, когда захочет напомнить KDC, что они уже общались И для KDC НЕТ необходимости запоминать, что Том сегодня уже аутентифицировался


Слайд 29

Выдача ключей – часть II: Получение Service Ticket на рабочую станцию Далее, вспоминаем, что Тому нужен Service Ticket на его рабочую станцию, поэтому, он предъявляет TGT на Ticket Granting Service Но как TGS может убедиться в том, что кто-нибудь не перехватил TGT Тома и не отправил его на TGS? Это достигается с помощью аутентификатора (“Authenticator”) – структуры данных, содержащей в себе, среди прочих вещей, штамп времени, зашифрованный ключом Tom-KDC


Слайд 30

Том запрашивает ST “Сейчас 12:10, 11 Мая 2010” Снова, Том создаёт штамп времени Затем, он отправляет свой запрос (“Тому нужен ST на TOMSPC”), “Authenticator” (это больше, чем просо штамп, но нам этого достаточно) и копию TGT на TGS, НЕ на AS Но на этот раз, он шифрует его, используя ключ сессии Tom-KDC, который он получил от AS ранее, а не свой NT hash


Слайд 31

TGS проверяет запрос Тома “Сейчас 12:10, 11 Мая 2010” KDC не помнит разговаривал ли он когда-либо с Томом раньше, но распознаёт TGT, который он выдал. Так как TGT зашифрован, используя пароль известный KDC (учётная запись krbtgt), он может расшифровать TGT и получить ключ сессии Tom-KDC. С помощью полученного ключа сессии Tom-KDC, KDC может расшифровать аутентификатор и извлечь из него штамп времени. Если штамп достаточно близок ко времени KDC, то TGS понимает, что это, действительно, Том просит Service Ticket на TOMSPC.


Слайд 32

TGS создаёт ST для TOMSPC Затем, TGS генерирует новый ключ сессии TPC-Tom, который Том и его рабочая станция TOMSPC (для краткости TPC) могут использовать сегодня Как и прежде, делается копия этого ключа Затем, TGS создаёт ST, содержащий ключ сессии TPC-Tom (и другие вещи) и шифрует его, используя пароль компьютера TPC TGS шифрует другую копию ключа, используя “пароль на сегодня” Tom-KDC TGS доставляет билет и новый ключ сессии Тому и забывает ключ Tom-KDC


Слайд 33

Том получает новый ключ Том видит новый билет на TOMSPC, но внутрь него заглянуть не может, так как не знает пароля компьютера. Но он знает пароль Tom-KDC, поэтому, он может расшифровать новый ключ сессии TPC-Tom, который можно использовать для общения со службой Workstation на компьютере TPC. Теперь всё готов для входа на рабочую станцию.


Слайд 34

Том аутентифицируется на TOMSPC “Сейчас 12:10, 11 Мая 2010” Том создаёт штамп времени Как и прежде, он шифрует его, чтобы доказать, что он является законным владельцем Service Ticket, который предъявляет, но на этот раз он шифрует его новым ключом TPC-Tom Он отправляет аутентификатор, Service Ticket и запрос “Эй, ты не хочешь впустить Тома?” на службу Workstation компьютера TOMSPC


Слайд 35

Том вошёл в систему Так же, как AS и TGS, служба Workstation на TOMSPC открывает билет, так как он зашифрован личным паролем TOMSPC TOMSPC находит внутри ключ TPC-Tom, который использует, чтобы открыть аутентификатор Затем, TOMSPC проверяет штамп времени, видит что он в порядке И Том снова аутентифицирован, но не авторизован… но авторизация – не работа Kerberos


Слайд 36

Приехали? Вход на PS – та же самая история Ещё один момент о билетах – помните аутентификатор? Он доказывает сервису, что пользователь, в самом деле, тот за кого себя выдаёт В Kerberos, мы можем дополнительно попросить сервис отправить обратно наш штамп времени, зашифрованный ключом сессии – это взаимная аутентификация (“Mutual Authentication”)


Слайд 37

Итак… Работа Kerberos – создавать произвольные пароли, которые используются как ключи сессии, чтобы аутентифицировать, не авторизовывать, пользователей и службы Эти ключи предоставляются пользователям в форме билетов Пользователи доказывают, что они являются законными владельцами билетов, используя аутентификаторы Kerberos работает только в AD; современные системы до сих пор используют LM, NTLM или NTLMv2 для аутентификации


Слайд 38

Дополнительные материалы How the Kerberos V5 Authentication Protocol Works http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx Блог команды Ask the Directory Services http://blogs.technet.com/askds/archive/tags/Kerberos/default.aspx IIS and Kerberos от Ken Schaefer http://www.adopenstatic.com/faq


Слайд 39

Спасибо! Надеюсь, это было полезно и интересно Stanky@stanky.ru


Слайд 40

Q & A


Слайд 41

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.


×

HTML:





Ссылка: