Служба kdc что это

Управление доступом и учетными записями (конспект лекции)

Субъект доступа – это лицо или процесс, действия которого регламентируются правилами разграничения доступа: учетная запись, пользователь или иная сущность, выполняющая какие-либо действия с объектами доступа.

Объект доступа – это единица информационного ресурса автоматизированной системы, доступ к которой регламентируется правилами разграничения доступа: файл, документ или иной объект, с которым взаимодействует субъект доступа.

Дискреционная модель управления доступом (Discretionary Access Control, DAC, от англ. Discretion – по усмотрению) – владелец объекта сам устанавливает и меняет права доступа субъектов. Минусы данной модели:

• ВПО, работающее в контексте «владельца» объекта, может получить доступ к этому объекту;

• Нет гарантий конфиденциальности информации при чтении данных из одного документа и записи в другой документ с другими правами доступа;

• Игнорирование атрибутов прав доступа при копировании файла на другое устройство (другой домен, другая ОС).

Мандатная модель управления доступом (Mandatory Access Control, MAC, от англ. Mandatory — обязательный) – использование меток/грифов конфиденциальности (англ. Classification) для объектов доступа и формы допуска (англ. Clearance) для субъектов доступа.

Основные правила (для защиты от утечек информации):

• Чтение только объектов, чей уровень безопасности не выше уровня субъекта доступа;

• Запись только в те объекты, чей уровень безопасности не ниже уровня субъекта доступа.

Ролевая модель управления доступом (Role-Based Access Control, RBAC) – предоставление прав доступа ролям (по функционалу), применяется для упрощения администрирования.

RBAC позволяет реализовать:

• Статическое разделение полномочий – невозможность одновременного присвоения субъекту нескольких ролей (например, для противодействия мошенничеству);

• Динамическое разделение полномочий – роли могут быть присвоены, но в каждый конкретный момент можно выполнять функции только одной из ролей (например, залогиниться только под кем-то одним).

Модель управления доступом на основании правил (Rule-Based Access Control, RuBAC) – предоставление доступа в соответствии с логическими правилами «если-то», задаваемыми администратором ИБ, например: размер документа не больше 5Мб, доступ только в будние дни в рабочее время и для сотрудников с формой допуска №3.

Контенто-зависимая модель управления доступом (Content-dependent Access Control) – предоставление доступа субъекту в зависимости от содержания объекта (прообраз DLP-системы предотвращения утечек данных).

Контекстно-зависимая модель управления доступом (Context-dependent Access Control) – предоставление доступа субъекту в зависимости от предыдущего запроса для невозможности агрегировать информацию (не даем субъекту больше, чем он должен знать, анализируя его предыдущие запросы).

Модель управления доступом на основании атрибутов (Attribute Based Access Control, ABAC) – предоставление доступа в зависимости от атрибутов субъекта, объекта, среды функционирования и самого действия в соответствии с логическими правилами «если-то», объединенными в политики. Является развитием модели RuBAC и одной из самых современных моделей управления доступом.

Риск-ориентированная модель управления доступом (Risk-Based/Adaptable Access Control) – предоставление доступа к объекту в зависимости от уровня риска субъекта доступа (IP-адрес, история ранее выполненных действий, скоринговый балл, иные атрибуты) и от ИБ-свойств самого объекта (атрибуты объекта, состояние защищенности, наличие инцидентов/уязвимостей на нем).

Права доступа к объекту описываются в ACL (access control list), состоящем из ACE (access control entries). Права доступа субъекта описываются в его Capability table.

Факторы аутентификации:

1. То, что субъект знает: пароли, парольные фразы, ключевые слова, контрольные вопросы.

2. То, чем субъект владеет: OTP, токены (программные, аппаратные), номер мобильного телефона, смарт-карты.

3. То, чем субъект является: биометрия (отпечатки пальцев, сетчатки глаз, радужной оболочки глаз, голос, изображение, походка).

OTP (one-time password) устройства:

1.1. time-based synchronization (TOTP): OTP получается смешиванием (имитовставкой) секретного ключа и текущего времени, этот OTP отправляется серверу вместе с ID пользователя, сервер сравнивает то, что он сам получил (время+ключ) и то, что пришло от пользователя. Есть некая временная дельта, в пределах которой сработает OTP.

1.2. counter-based synchronization (HOTP — HMAC-based OTP): пользователь нажимает на кнопку на OTP-брелке, OTP получается смешиванием (имитовставкой) секретного ключа и значения счетчика, дальше это значение отправляется для проверки на сервер, который «знает» множество возможных значений счетчика в каждый момент времени.

Модель «запрос-ответ» (challenge-response): сервер отправляет запрос-challenge (или nonce, некая рандомная величина) пользователю, который вводит её в токен, токен с использованием секретного ключа формирует OTP. Далее пользователь вводит свой ID и этот OTP на странице сервера для аутентификации.

Примеры второго фактора: ruToken,RSA SecurID, FIDO U2F, Google/Microsoft Authenticator

FAR — false acceptance rate – уровень ложного предоставления доступа (пустили злоумышленника в помещение).

FRR — false rejection rate – уровень ложного отказа в доступе (не пускаем легитимного пользователя).

CER — crossover error rate – уровень пересечения ошибок (чем он ниже, тем более точная система, т.е. при приемлемом уровне false acceptance/rejection мы сохраняем высокий процент прохода легитимных юзеров).

На графике CER – это точка, в которой кривые false rejection rate и false acceptance rate пересекаются (т.е. когда false rejection rate = false acceptance rate).

Ошибки I рода (False Positive) (ложноположительные срабатывания) – неверно детектируем чистое письмо как спам.

Ошибки II рода (False Negative) (ложноотрицательные срабатывания) – не задетектировали спам как спам и пропустили во «Входящие».

True Positive – спам верно задетектировали как спам.

True Negative – чистое письмо верно задетектировали как чистое.

NTLM — NT LAN Manager, протокол сетевой аутентификации в инфраструктуре Microsoft. Основан на использовании NTLM-хэша пароля пользователя в качестве секретного ключа и на знании сервером NTLM-хэша пароля пользователя для его аутентификации. Старые версии LM, NTLMv1 небезопасны, не применяются.

NTLMv2 – взаимная аутентификация клиента и сервера, использование меток времени (для исключения накопления и повторного использования устаревших данных аутентификации).

Атака Pass The Hash — возможность использования NTLM-хэша от пароля пользователя для получения доступа к ресурсам из-под его УЗ по NTLM-хэшу, без необходимости получения самого пароля.

Утилиты для атаки Pass The Hash:

• Mimikatz – получение NTLM-хэшей и их повторное использование для имперсонации учетной записи.

• Procdump (официальная утилита Microsoft) – доступ к памяти системного процесса lsass.exe, хранящего NTLM-хэши, для последующего брутфорса или повторного использования.

• Работа с hiberfil.sys (файл, хранящий данные ОЗУ во время гибернации – закрытие крышки ноутбука).

Kerberos — протокол сетевой аутентификации для гетерогенных сред, использует симметричное шифрование. Также основан на использовании NTLM-хэша пароля пользователя в качестве секретного ключа и на знании Керберос-сервером NTLM-хэша пароля пользователя для его аутентификации. Пароли (хэши) не передаются по сети, не требуется множественная аутентификация для работы с различными сервисами в пределах Керберос-домена, происходит взаимная аутентификация клиента и сервера.

1. KDC (key distribution center) — содержит в себе все закрытые ключи (secret key) пользователей и сервисов, они доверяют KDC. KDC — единая точка отказа, должен быть всегда online.

2. AS (authentication service) — компонент KDC, принимает запросы от пользователей.

3. TGS (ticket granting service) — компонент KDC, который принимает запросы на сессионные ключи (TGS-тикеты/мандаты) и выдаёт их.

4. TGT (ticket granting ticket) — тикет/мандат, который выдаётся AS’ом в зашифрованном виде клиенту на некоторое время (Windows default setting — 10 часов), далее клиент его использует для подтверждения того, что он уже был авторизован.

Описание процесса аутентификации с использованием Керберос:

1. Клиент обращается к AS для получения TGT. Клиент пересылает данные (идентификатор клиента, метку времени и идентификатор сервера), зашифрованные NTLM-хэшем от пароля (секретным ключом) клиента. Этот пакет данных называется AS-REQ.

2. AS расшифровывает запрос клиента (связываясь с KDC для получения секретного ключа клиента); если всё ОК, то возвращает клиенту TGT, зашифрованный ключом TGS’а (т.е. NTLM-хэшем служебного пользователя KRBTGT), а также сессионный ключ связи «клиент/TGS», зашифрованный ключом клиента. Этот пакет данных называется AS-REP. Сам TGT может быть открыт и прочитан только сервисом KRBTGT.

3. Когда клиент хочет использовать сервис, то клиент шлёт в TGS свой TGT, идентификатор сервиса и свой зашифрованный сессионным ключом «клиент/TGS» аутентификатор (ID клиента, timestamp). Этот пакет данных называется TGS-REQ.

а) TGS-тикетом, который зашифрован секретным ключом сервиса (т.е. NTLM-хэшем пароля сервисной УЗ) и содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата, сессионный ключ «клиент/сервис»;

б) сессионным ключом «клиент/сервис», зашифрованный сессионным ключом «клиент/TGS».

Этот пакет данных называется TGS-REP.

5. Клиент отправляет сервису этот TGS-тикет и свой новый аутентификатор (тоже метка времени, ID клиента, зашифрован сессионным ключом «клиент/сервис»). Этот пакет данных называется AP-REQ.

6. Сервис расшифровывает тикет своим закрытым ключом, извлекает сессионный ключ «клиент/сервис», потом полученным сессионным ключом «клиент/сервис» расшифровывает аутентификатор клиента, и чтобы себя аутентифицировать перед клиентом отправляет ему значение «метка времени клиента+1», зашифрованное сессионным ключом «клиент/сервис». Этот пакет отправляемых данных называется AP-REP.

7. Клиент расшифровывает «метку времени+1», проверяет, если ОК — начинается обмен инфрмацией.

Схема работы Керберос:

Domain Controller = KDC+AS

Application Server = сервис, требующийся клиенту, работающему на User’s Workstation

Атаки на Kerberos:

• доступ к сессионным ключам;

• доступ к секретным ключам (NTLM-хэшам от паролей пользователей и сервисов).

Старая реализация Керберос-шифрования с шифронабором «RC4_HMAC_MD5» использует «несоленый» (всегда одинаковый) NTLM-хэш от пароля атакуемого пользователя для шифрования запроса, поэтому получив этот хэш можем запросить тикет от имени атакуемой УЗ (атака Skeleton). Более новая реализация Керберос-шифрования с шифронабором «AES256_HMAC_SHA1» использует уже «соленый» NTLM-хэш (хэш каждый раз получается разным, т.к. его значение зависит не только от пароля пользователя, но и от некой переменной – «соли»).

Pass The Ticket — возможность использования пользовательского TGS или TGT-билета Керберос для получения доступа к ресурсам из-под УЗ (например, путем доступа к памяти процесса lsass.exe, в котором хранятся Керберос-тикеты).

Golden Ticket — возможность выдавать себя за любого пользователя в домене, используя NTLM-хэш учетной записи KRBTGT и выдавая любые TGT кому угодно.

Silver Ticket — возможность использования NTLM-хэша от пароля ПК или сервиса для создания TGS/TGT и получения доступа к ресурсам из-под этой УЗ.

Kerberoasting — возможность брутфорса и получения пароля сервисной УЗ в офлайне (без риска блокировки аккаунта).

Overpass The Hash — возможность подделки TGT любого пользователя при наличии NTLM-хэша от его пароля.

Защита учетных записей:

• Identity & Access Management системы

• HR-системы (актуальная информация)

• Системы токенизации (предоставление временного псевдо-пароля)

• Смарт-карты (вход не по паролю, а по сертификату)

• Программы повышения осведомленности

• Фишинговые учебные рассылки

• Работа с пользователями

• Доступ при наличии подтвержденной служебной необходимости и при наличии согласования от руководителя

Kerberos для специалиста по тестированию на проникновение. Часть 1. Теория

На мой взгляд специалисту по тестированию на проникновение инфраструктуры на базе Active Directory важно понимать общее устройство протокола Kerberos. Вот лишь несколько причин почему:

• Знание устройства протокола Kerberos необходимо для понимания ряда классических атак.
• Периодически появляются новые атаки, но прежде чем приступать к их эксплуатации, необходимо разобраться к каким последствиям они могут привести. Без знания Kerberos это порой затруднительно, либо вовсе невозможно.
• Личная чуйка, что если человек называет себя специалистом, то он должен обладать несколько более глубокими знаниями, чем название инструмента или кнопки, на которую надо нажать.

Про Kerberos и атаки на него уже написано немало статей. Многие из указанных статей предназначены либо для математиков, либо для сетевых инженеров, либо для специалистов по тестированию на проникновение. Материал часто преподносится однобоко в разрозненной форме и приходится тратить много времени для отбора действительно полезных работ и их склейки на полях личных заметок.

В этом цикле статей буду пытаться разобрать, как в теории устроен протокол Kerberos и какие атаки с его использованием можно осуществить на практике в Active Directory. Также будут приведены некоторые рекомендации по противодействию рассматриваемым атакам.

В первой части будет рассмотрено устройство Kerberos в общем случае, а также реализация Kerberos в Active Directory.

К материалу не стоит относится как к истине в последней инстанции. Только дураки не сомневаются.

Экскурс. Краткий и исторический#

Протокол Kerberos был разработан в MIT, как часть научно-исследовательского проекта Афина, предназначенного для создания распределенной образовательной среды. К 1988 году проект достиг поставленных целей. В частности, было опубликовано описание протокола Kerberos v4, являющегося основой системы единого входа в разработанную среду. Предыдущие версии 1-3 были ранними прототипами и не использовались за пределами MIT.

В 1989 году состоялся официальный релиз Kerberos v4.

Однако протоколу было куда развиваться. Например, можно выделить следующие недостатки Kerberos v4:

• Использование слабых криптографических алгоритмов.
• Уязвимости в архитектуре протокола, позволяющие проводить ряд атак методом оффлайн-перебора в отношение паролей пользователей.
• Отсутствие возможности делегирования учетных данных или использования дополнительных факторов аутентификации.

C целью устранения приведенных недостатков в 1993 году вышел новый протокол Kerberos v5.

В 1999 году Microsoft объявила о поддержке Kerberos v5 в своей будущей операционной системе Windows 2000, что было впоследствии реализовано в качестве соответствующего компонента Active Directory. До этого для аутентификации в рабочих группах на базе операционной системы Windows использовался протокол NT LAN Manager (NTLM), одна из версий которого (NTLM v2) применяется для локальной аутентификации в современных системах до сих пор. Подробное рассмотрение протокола NTLM v2 выходит за рамки статьи. Важно отметить, что указанный протокол также обладает рядом недостатков, которые было решено избежать при внедрении Kerberos v5 в Windows 2000.

В настоящее время Kerberos v5 можно считать довольно возрастным протоколом, тем не менее он используется во множестве различных систем, а не только в Active Directory. Вот неполный перечень:

• Amazon Web Services
• Apple macOS
• Google Cloud
• Microsoft Azure
• Oracle Solaris
• Red Hat Linux

Всюду далее речь будет идти именно о Kerberos v5. Для читаемости Kerberos v5 будет называться просто Kerberos.

Требования к протоколу Kerberos#

Разобраться с принципом работы протокола Kerberos поначалу не просто. Постоянно приходится перечитывать ранее изученный материал и держать в голове множество деталей. Периодически возникает вопрос: почему все так сложно устроено?

Чтобы корректно ответить на заданный вопрос и, что не менее важно, понять ответ, требуется обладать познаниями в устройстве криптографических протоколов, а также смежных дисциплинах. Полагаю, что копать настолько глубоко смысла нет. Все же чтобы понимать, чем обусловлены навороты Kerberos приведу ряд требований, которым протокол должен был отвечать:

Подразумевается, что обмен сообщений осуществляется с доверенных устройств, но в открытой недоверенной среде. Сетевой трафик может быть прослушан злоумышленником, а передаваемые сообщения могут быть подменены или перенаправлены. Таким образом секреты участников протокола ни при каких условиях не должны передаваться по сети в открытом виде.

Любопытный факт: Kerberos разрабатывался до появления SSL.

Информация о пользователях и их секретах должна хранится в выделенном месте. Это ограничение обусловлено следующими соображениями:

• Необходимо минимизировать количество критических объектов, которые требуется защищать.
• Добавление нового, удаление старого, изменение текущего секрета у клиента или сервиса не должно требовать уведомления всех остальных участников протокола. Думаю, полезной будет следующая иллюстрация:

Варианты сетей без и c выделенным доверенным центром

• Должна поддерживаться технология единого входа (Single Sign-On). Это ограничение обусловлено тем, что пользователю неудобно каждый раз при обращении к ресурсу заново вводить пароль.
• Успешное окончание работы протокола должно означать успешную взаимную аутентификацию сторон.
• В результате работы протокола между клиентом и сервисом должен быть сформирован секретный сессионный ключ. Знание сессионного ключа позволяет злоумышленнику расшифровать некоторые старые сообщения, но организовать новую сессию с использованием уже известного сессионного ключа не получится.

Список терминов#

Прежде чем приступить к технической части определимся с терминологией, чтобы в дальнейшем избежать путаницы.

Kerberos – в первую очередь протокол аутентификации, но при этом предусматривающий возможность транспортировки информации необходимой для авторизации.

Важно не путать:

Аутентификация – процесс проверки подлинности. То есть проверка того, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация – процесс проверки прав доступа. Авторизация может быть применена только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, необходимо выяснить личность объекта, которому указанные права планируется предоставить.

Сервер – сетевой объект, обеспечивающий функционирование одного или нескольких сервисов. Примеры серверов: файловый сервер, почтовый сервер.

Клиент – объект, обращающийся к сервису с целью получения доступа к ресурсам. Примеры клиентов: учетная запись или рабочая станция пользователя.

Область действия (Realm) – совокупность клиентов, серверов и сервисов, участвующих в протоколе Kerberos.

Принципал (Principal) – это строка, полностью идентифицирующая участника протокола Kerberos.

Принципал может быть именем сервиса (Service Principal Name), или именем клиента (User Principal Name). Форматы принципалов для клиентов и сервисов различаются.

Принципал клиента имеет следующую форму: principal-name[/instance-name]@REALM Пример: имя пользователя — Ivan, а область действия — DOMAIN.LOCAL, то полный принципал будет Ivan@DOMAIN.LOCAL.

Расширение instance-name является опциональным и позволяет любому пользователю иметь более одного принципала. Так, если Ivan является администратором области DOMAIN.LOCAL, имя принципала будет Ivan/admin@DOMAIN.LOCAL, и у этого принципала будут другие права (и удостоверяющие данные).

Принципал сервиса имеет следующую форму: service-name/host[:port]@REALM, где

• service-name – это специфичная для приложения строка, идентифицирующая сервис на этом хосте.
• host – это доменное имя хоста, на котором работает сервис
• port — порт на котором запущена служба.

Пример: для сервиса ftp, работающего на хосте с именем fileserver.example.com в области @EXAMPLE.COM, имя принципала сервиса будет ftp/fileserver.example.com@EXAMPLE.COM.

Почему такое внимание уделяется этим именам? В дальнейшем будет понятнее, но уже сейчас можно отметить, что в Kerberos для идентификации сервера требуется именно принципал (имя), тогда как в NTLM может использоваться IP-адрес.

Примечание: возможность использования IP-адресов была добавлена в новых клиентах Windows.

Рассмотрим пример: есть рабочая станция (DNS-имя: station.domain.local, IP-адрес: 192.168.10.12) с общедоступной сетевой папкой scan. При открытии проводника и переходу по UNC-пути \\station.domain.local\scan будет использоваться Kerberos, но при указании UNC-пути \\192.168.10.12\scan будет использоваться NTLM, так как принципал отсутствует. В частности, поэтому администраторы не любят отключать NTLM, так как устаревшее сетевое оборудование (принтеры, роутеры и пр.) может быть настроено со статическими IP-адресами или вовсе не поддерживать Kerberos.

Центр распределения ключей (Key Distribution Center, далее – KDC) является доверенным центром аутентификации для всех участников протокола Kerberos в рамках определенной области действия.

KDC включает в себя следующие компоненты:

• База данных Kerberos, предназначенная для хранения информации о всех принципалах и их секретах.
• Сервер аутентификации (Authentication Server, AS), обрабатывающий запросы на аутентификацию клиентов к области действия протокола Kerberos;
• Сервер выдачи разрешений (Ticket Granting Server, TGS), обрабатывающий запросы на аутентификацию к определенному сервису, функционирующего в составе указанной области действия.

Проиллюстрируем вышесказанное следующей зарисовкой:

Участники протокола Kerberos

Аутентификация с использованием Kerberos#

Иллюстрация порядка изложения материала

Начнем от общего и перейдем к частному.

Житейская аналогия#

Рассмотрим немного выдуманную, но полезную для последующих аналогий ситуацию. Представим парк развлечений. Допустим, что перечень разрешенных посетителей парка содержится в специальной базе данных. Для тех, кто в базе отсутствует проход воспрещен. Как организовано посещение парка:

1. Посетитель приходит на вход и показывает охраннику свой паспорт.
2. Охранник проверяет наличие посетителя в базе данных.
3. Охранник выдает посетителю суточный билет на посещение парка.
4. Посетитель выбирает понравившийся ему аттракцион и идет на кассу, чтобы получить билет.
5. На кассе проверяют суточный билет посетителя и выдают билет на аттракцион.
6. Посетитель идет на выбранный аттракцион и показывает смотрителю аттракциона, полученный на кассе билет.
7. Смотритель проверяет билет и пропускает посетителя.
8. Посетитель при желании может посмотреть бейджик смотрителя, чтобы убедиться, что он действительно сотрудник парка.

Если посетитель захотел пойти на другой аттракцион, он снова идет на кассу и показывает суточный билет. Далее повторяется процесс из шагов 5, 6, 7 только с другим смотрителем и другим аттракционом.

По верхам в общем виде#

Теперь по аналогии рассмотрим упрощенную схему аутентификации с использованием Kerberos:

Общая схема обмена запросами в Kerberos

1. Клиент отправляет запрос на аутентификацию к области действия.
2. Сервер аутентификации проверяет подлинность Клиента с использованием Базы данных Kerberos.
3. Сервер выдает Клиенту разрешение (пока просто назовем его TGT) на получение отдельных разрешений (далее – ST), требующимся для доступа к сервисам, входящим в область действия.
4. С использованием полученного на шаге №3 разрешения (TGT) Клиент запрашивает разрешение на доступ к Сервису А («ST для А»).
5. Сервер выдачи разрешений проверяет TGT и выдает Клиенту ST для доступа к сервису А.
6. Клиент с использованием «ST для А» запрашивает у Сервиса А доступ к его ресурсам.
7. Сервис А проверяет «ST для А» и предоставляет Клиенту доступ к своим ресурсам. При необходимости сервис также проходит аутентификацию перед клиентом.

В дальнейшем при необходимости доступа к другому сервису:

1. С использованием полученного на шаге №3 разрешения (TGT) Клиент запрашивает разрешение на доступ к Сервису Б («ST для Б»).
2. Сервер выдачи разрешений проверяет TGT и выдает Клиенту ST для доступа к сервису Б.
3. Клиент с использованием «ST для Б» запрашивает у Сервиса Б доступ к его ресурсам.
4. Сервис Б проверяет «ST для Б» и предоставляет Клиенту доступ к своим ресурсам.

Видно, что стороны обмениваются сообщениями, содержащими запросы и ответы с разрешениями. Официально форматы указанных сообщений задокументированы в RFC 4120.

Теперь переназовем передаваемые сообщения в соответствие с RFC:

• Запрос на аутентификацию к области действия (шаг 1) — сообщение KRB_AS_REQ.
• Ответ сервера на запрос аутентификации клиента (шаг 3) – сообщение KRB_AS_REP.
• Разрешение на получение разрешений – TGT (Ticket Granting Ticket).

Другие встречающиеся в литературе названия: мандат / билет на получение разрешений, первичное удостоверение пользователя.

Примечание: в различных источниках часто встречается словосочетание «TGT билет», но в аббревиатуре TGT уже заложено слово «билет» — Ticket Granting Ticket, поэтому правильнее говорить просто «TGT».

Запрос на доступ к сервису (шаг 4) – сообщение KRB_TGS_REQ.

Ответ сервера выдачи разрешений (шаг 5) – сообщение KRB_TGS_REP.

Разрешение на доступ к сервису – ST (Service Ticket) Другие встречающиеся названия: TGS билет, билет сервиса, мандат сервиса.

Запрос клиента на аутентификацию к сервису (шаг 6) – сообщение KRB_AP_REQ.

Опциональный ответ с аутентификацией сервиса перед клиентом (шаг 7) – сообщение KRB_AP_REP.

Чтобы проще было запомнить:

Далее каждый запрос будет разобран подробнее.

Разбор аутентификации в Kerberos согласно RFC#

В начале имеются три участника протокола Kerberos:

1. Клиент
2. Сервис
3. Центр распределения ключей

Каждый из участников обладает своим долговременным секретом (ключом). Кроме того, центр распределения ключей обладает секретами всех участников.

Рис. 3 — Первоначальное распределение секретов

Алгоритм формирования ключа#

Ключ формируется как результат работы хэш-функции под названием string2key. Хэш может вычисляться разными способами в зависимости от соответствующих настроек Kerberos, в частности поддерживаются следующие алгоритмы:

Название алгоритма (etype)	Способ вычисления ключа
RC4_HMAC_MD5	NT-хэш пароля участника
AES128_CTS_HMAC_SHA1_96	PBKDF2(пароль, соль*, kvno**, 128)
AES256_CTS_HMAC_SHA1_96	PBKDF2(пароль, соль*, kvno**, 256)

В последних версиях Windows по умолчанию используется шифрование AES. Но для совместимости с системами ниже Windows Vista и Windows 2008 Server необходима поддержка алгоритма RC4.

Соль формируется следующим образом:

Для доменных пользователей: полностью определенное имя домена заглавными буквами (FQDN) + регистр зависимое имя пользователя.

Для компьютеров: FQDN + host + регистр зависимое имя компьютера без $ в конце.

kvno — key version number (в переводе — номер версии ключа). kvno представляет собой счетчик, увеличивающий значение каждый раз при смене пароля.

Таким образом, у одного и того же пользователя в разных доменах или для разных учетных записей будут разные секреты (хэши паролей), даже если пароль одинаковый. То есть строить радужные таблицы для указанных хэшей нецелесообразно.

KRB_AS_REQ#

Клиент отправляет серверу аутентификации запрос, содержащий:

• Принципал клиента
• Срок жизни билета

Примечание: если это не первый материал по Kerberos, который вы читаете и возникает вопрос, почему отсутствует предварительная аутентификации, то поясню – это дополнительная настройка протокола, которая в «классической» реализации по умолчанию отключена. В реализации Kerberos для Active Directory, указанная настройка напротив по умолчанию активна и этот случай будет рассмотрен чуть позже.

KRB_AS_REP#

Сервер аутентификации по полученному принципалу находит в базе Kerberos секрет клиента. Кроме того, для дальнейшего общения с KDC сервер аутентификации случайным образом генерирует сессионный ключ. В итоге в ответ клиенту отправляются два сообщения.

Первое сообщение зашифровано с использованием секрета клиента и содержит:

• Сессионный ключ для KDC
• Метка времени
• Срок жизни TGT

Второе сообщение (TGT) зашифровано уже с использованием (!) секрета KDC и включает в себя те же самые данные, что и первое сообщение, но вместе с принципалом клиента.

Примечание: время жизни TGT определяется, как наименьшее время среди запрошенного клиентом и хранящегося в настройках центра распределения ключей.

Клиент, приняв ответ, может расшифровать только первое сообщение. Таким образом он получает сессионный ключ для дальнейшего общения с KDC. TGT также сохраняется у клиента в зашифрованном виде.

KRB_TGS_REQ#

Теперь, пройдя аутентификацию, клиент желает получить доступ к какому-то сервису. Для этого он отправляет серверу выдачи разрешений запрос, содержащий:

• Принципал сервиса
• Аутентификатор, состоящий из принципала клиента и метки времени, зашифрованных с использованием извлеченного ранее сессионного ключа для общения с KDC.
• Сохраненный TGT

Приняв запрос, сервер выдачи разрешений прежде всего выполняет проверку полученных данных. Сначала с использованием секрета KDC сервер расшифровывает TGT (1) и по метке времени со сроком действия убеждается, что TGT не протух (2).

Далее сервер извлекает сессионный ключ для KDC. Несмотря на то, что указанный ключ был создан в KDC, нужды хранить его в базе Kerberos нет. Действительно, TGT не может быть изменен кем-либо кроме KDC, поэтому полученным из него данным можно доверять.

Возникает важный вопрос — почему можно быть уверенным, что TGT не отправлен злоумышленником, перехватившим его при прослушивании сетевого трафика? Для этого в запросе прилагается аутентификатор. Аутентификатор зашифрован с использованием сессионного ключа KDC, который мог быть извлечен из KRB_AS_REP запроса только определенным клиентом. Метка времени добавляется с целью предотвращения атак методом повтора, чтобы злоумышленник не смог вставить в свой запрос старый аутентификатор клиента, перехваченный из прошлых сообщений.

Сервер выдачи разрешений сравнивает принципалы пользователя из TGT и аутентификатора, а также убеждается, что аутентификатор был сформирован не более двух минут назад.

KRB_TGS_REP#

В случае успешного завершения проверок сервер выдачи разрешений отправляет клиенту ответ, содержащий два сообщения. Первое сообщение зашифровано с использованием сессионного ключа для KDC и содержит:

• Сессионный ключ для общения с сервисом
• Метка времени
• Срок жизни TGS билета
• Принципал сервиса

Второе сообщение (TGS билет) зашифровано с использованием секрета сервиса и включает в себя те же самые данные, что и первое сообщение, а также принципал клиента.

Клиент, приняв ответ, может расшифровать только первое сообщение. Таким образом он получает сессионный ключ для дальнейшего общения с сервисом. TGS билет сохраняется у клиента в зашифрованном виде.

KRB_AP_REQ#

Клиент отправляет сервису запрос на получение доступа, содержащий:

• Аутентификатор, состоящий из принципала клиента и метки времени, зашифрованных с использованием извлеченного ранее сессионного ключа для общения с сервисом.
• Сохраненный TGS билет
• Флаг взаимной аутентификации

Приняв запрос, сервис прежде всего выполняет проверку полученных данных. Сначала с использованием своего секрета сервис расшифровывает TGS (1) и по метке времени со сроком действия убеждается, что TGS не протух (2). Далее сервис извлекает сессионный ключ.

TGS билет не может быть изменен кем-либо кроме того, кто знает секрет сервиса, а это KDC и сам сервис. Сервис доверяет KDC, таким образом извлеченным из TGS билета данным сервис также может доверять.

Аналогично KRB_TGS_REQ расшифровывается аутентификатор и выполняются другие проверки. Обратите внимание, что сервис удостоверяется в подлинности клиента, не обращаясь к KDC.

KRB_AP_REP#

Опционально, в случае если активен флаг взаимной аутентификации, сервис также подтверждает перед клиентом свою подлинность, отправив ответ с меткой времени, зашифрованной с использованием сессионного ключа.

Kerberos в Active Directory#

«Чтобы донести идею её надо рассказать три раза, но разными словами» (с)

Рассмотрим реализацию Kerberos в Active Directory. Уточним терминологию, теперь:

Область действия – домен.

Центр распределения ключей – контроллер домена.

Сервер аутентификации и сервер выдачи разрешений – оба объединены в рамках одного компонента, функционирующего на контроллере домена.

База данных Kerberos – в Active Directory информация о секретах пользователей хранится на контроллерах домена в файле ntds.dit.

krbtgt – название учетной записи, по умолчанию создаваемой вместе с доменом и обладающей секретом контроллера домена.

В итоге с учетом переименований получается следующая структура:

В целом в Active Directory Kerberos работает согласно RFC, но есть ряд особенностей. Рассмотрим указанные особенности на следующем примере.

Доменная аутентификация пользователя к рабочей станции в Active Directory#

Изначально на рабочей станции активно следующее диалоговое окно:

Пользователь вводит свои учетные данные (название домена, имя учетной записи, пароль) и жмет «OK». Далее компонент, ответственный за отображение диалогового окна, передает запрос на аутентификацию пользователя с использованием введенных данных в локальный центр безопасности (Local Security Authority, LSA). Центр содержит различные динамические библиотеки, предоставляющие функции для процедур аутентификации, смены паролей, а также выдачи токенов. Указанные библиотеки вызываются и работают в контексте процесса lsass.exe (Local Security Authority Subsystem Service).

В зависимости от запроса для его обработки согласовывается соответствующая библиотека. Примеры библиотек и протоколов:

• msv1_0.dll (NTLM)
• kerberos.dll (Kerberos)
• SChannel.dll (TLS/SSL)
• WDigest.dll (digest аутентификация)

По умолчанию для обработки запросов на проверку подлинности пользователя при входе в домен выбирается библиотека kerberos.dll, реализующая одноименный протокол.

Следует понимать, что пользователь никогда напрямую не взаимодействует с системой. Система олицетворяет пользователя и получает доступ к необходимым ресурсам с использованием прав доступа, которыми указанный пользователь обладает. Таким образом систему в ходе аутентификации можно рассматривать как сервис.

В итоге имеем следующую картину:

Секрет системы (ключ) присваивается рабочей станции при ее добавлении в домен. Важно отметить, что введенный пользователем пароль не хранится в памяти рабочей станции. Ключ пользователя формируется при помощи ранее рассмотренной хэш-функции string2key.

Далее процесс, обеспечивающий аутентификацию пользователя, обращается к контроллеру домена с использованием сформированного ключа. Здесь проявляется одна из особенностей реализации Kerberos в Active Directory – предварительная аутентификация по умолчанию включена.

KRB_AS_REQ с предварительной аутентификацией#

В этом случае клиент отправляет серверу аутентификации запрос, содержащий:

• Принципал клиента
• Метку времени, зашифрованную с использованием секрета клиента

Получив запрос, контроллер домена с помощью секрета клиента расшифровывает метку времени и сравнивает её с текущим значением. Если переданное время расходится с текущим меньше чем на пять минут, то значит предварительная аутентификация клиента успешно пройдена. В противном случае контроллер отправляет сообщение об ошибке.

KRB_AS_REP (AD)#

В случае успешного прохождения предварительной аутентификации контроллер домена отправляет рабочей станции ответ, аналогичный рассмотренному в разделе про RFC.

В ответе появилась еще одна особенность, а именно новое поле «PAC» в содержимом TGT.

PAC (Privilege Attribute Certificate) это данные, предназначенные для авторизации пользователя. Ранее уже отмечалось, что кроме аутентификации Kerberos может использоваться при авторизации, но не пояснялось как. Поле PAC изначально было предусмотрено в RFC без конкретного описания содержимого. Какая информация передается в PAC и как она обрабатывается зависит от конкретной реализации Kerberos.

В Active Directory PAC среди прочего содержит следующую информацию:

• Идентификатор безопасности (SID) учетной записи пользователя
• Идентификаторы групп, в которых состоит пользователь

Указанная информация дважды подписывается. Одна подпись принадлежит krbtgt, а вторая сервису, к которому обращался клиент (в случае KRB_AS_REP тоже krbtgt).

KRB_TGS_REQ (AD)#

Запрос производится аналогично рассмотренному ранее в RFC.

KRB_TGS_REP (AD)#

PAC из TGT, полученный в предыдущем сообщении, помещается в TGS билет. В этот раз PAC подписывается не только с использованием секрета krbtgt, но и секрета системы.

LOGON#

С использованием сессионного ключа LSA извлекает подписанный PAC из TGS билета. LSA проверяет подпись PAC при помощи секрета системы и далее с учетом добытых из PAC доменных групп безопасности формирует процесс Winlogon c соответствующим токеном доступа клиента.

Опционально система может запросить контроллер домена выполнить дополнительную проверку подписи с PAC с помощью секрета krbtgt.

Думаю, для поверхностного знакомства с Kerberos достаточно. Несмотря на то, что многие моменты остались за скобками, представленного материала в целом хватает для понимания атак на протокол Kerberos, которые рассмотрим в следующей части.

Введение в механизм безопасности Hadoop Kerberos

До версии Hadoop 1.0.0 или CDH3 в hadoop не было сертификации безопасности. По умолчанию все узлы в кластере являются надежными и заслуживающими доверия. Пользователям не нужно проверять при взаимодействии с HDFS или M / R. В результате злонамеренные пользователи притворяются настоящими пользователями или серверами, которые вторгаются в кластер hadoop, злонамеренно отправляют задания, изменяют состояние JobTracker, подделывают данные в HDFS и притворяются, что это NameNode или TaskTracker для принятия задач. Хотя HDFS добавила разрешения для файлов и каталогов после версии 0.16, строгая аутентификация не гарантируется, и эти разрешения могут защитить только от случайной потери данных. Вредоносные пользователи могут легко притвориться другими пользователями, чтобы подделать разрешения, так что разрешения будут установлены как ложные. Он не может гарантировать безопасность кластера Hadoop.

После версии Hadoop 1.0.0 или CDH3 был добавлен механизм аутентификации Kerberos. Сделайте узлы в кластере тем, на что они претендуют и которым доверяют. Kerberos может поместить ключ аутентификации на надежном узле заранее, когда кластер развернут. Когда кластер работает, узлы в кластере аутентифицируются с помощью ключа. Только сертифицированные узлы могут использоваться нормально. Узел, пытающийся олицетворять, не может обмениваться данными с узлами в кластере, поскольку у него нет ключевой информации, полученной заранее. Проблема злонамеренного использования или вмешательства в кластер Hadoop предотвращается, а надежность и безопасность кластера Hadoop обеспечиваются.

2. Проблемы безопасности Hadoop

2.1 Проблема аутентификации пользователя на сервере

• NameNode, нет аутентификации пользователя на JobTracker

Пользователи могут маскироваться под других пользователей и вторгаться в кластер HDFS или MapReduce.

• Нет аутентификации на DataNode

Датоде не аутентифицирует чтение и вывод. В результате, если некоторые клиенты знают идентификатор блока, они могут произвольно получить доступ к данным в блоке на узле данных.

• Нет сертификации на JobTracker

Может произвольно убить или изменить работу пользователя, может изменить статус работы JobTracker

2.2 Проблемы межсерверной аутентификации

• Нет DataNode, сертификация TaskTracker

Пользователи могут притворяться датодами и треккерами, чтобы принимать задания от JobTracker и Namenode.

3. Kerberos может решить проблему аутентификации безопасности Hadoop

Kerberos реализует аутентификацию безопасности на уровне машины, которая является проблемой аутентификации между сервисами, упомянутой ранее. Заранее машины, идентифицированные в кластере, вручную добавляются администратором в базу данных kerberos, а ключевые таблицы хоста и каждого узла (включая имя хоста и соответствующий узел и ключ между ними) генерируются на KDC, Эти ключевые таблицы распределяются по соответствующим узлам. Посредством этих файлов keytab узел может получить ключ для связи с целевым узлом из KDC, а затем аутентифицироваться целевым узлом для предоставления соответствующих услуг, предотвращая возможность олицетворения.

• Решить межсерверную аутентификацию

Kerberos распределяет таблицу ключей на все машины в кластере и использует ключи для связи друг с другом, чтобы гарантировать, что они не олицетворяют сервер. Машины в кластере — это то, что они называют надежным.

Запретите пользователям притворяться Datanode, Tasktracker и принимать JobTracker, Namenode, назначение задач.

• Решить аутентификацию клиента на сервере

Kerberos обеспечивает аутентификацию доверенных клиентов, чтобы гарантировать, что они могут выполнять операции, связанные с заданием. Запретить пользователям злонамеренно выдавать себя за клиентов, отправляющих задания.

Пользователи не могут притворяться другими пользователями и вторгаться в кластер HDFS или MapReduce

Даже если пользователь знает соответствующую информацию о датоделе, он не может прочитать данные в HDFS.

Пользователи не могут отправлять операции с заданиями в JobTracker

• Нет аутентификации на уровне пользователя

Невозможно контролировать работу пользователей, отправляющих задания. Невозможно ограничить полномочия пользователей отправлять задания. Нет контроля над тем, какие пользователи могут отправлять задания этого типа и какие пользователи не могут отправлять задания этого типа. Они контролируются модулем ACL (ссылка)

4. Введение принципа работы Kerberos

4.1 Основные понятия

Princal (безопасный человек): аутентифицированный человек с именем и паролем

KDC (центр распространения ключей): это сетевой сервис, который предоставляет билет и временный сеансовый ключ

Билет: запись, используемая клиентами для подтверждения своей личности на сервере, включая идентификацию клиента, ключ сеанса и отметку времени.

AS (сервер аутентификации): сервер аутентификации

TSG (Сервер предоставления билетов): сервер лицензий

4.2 Как работает Kerberos

4.2.1 Протокол Kerberos

Kerberos можно разделить на две части:

• Клиент отправляет свою собственную идентификационную информацию в KDC, и KDC получает TGT (билет для выдачи билетов) от Службы выдачи билетов и шифрует TGT для Клиента, используя ключ между Клиентом и KDC, до запуска протокола. В это время только реальный клиент может расшифровать зашифрованный TGT, используя ключ между ним и KDC, тем самым получив TGT. (Этот процесс предотвращает прямую отправку Клиентом пароля в KDC небезопасным способом прохождения проверки)
• Клиент использует ранее полученный TGT для запроса билетов KDC на другие услуги, чтобы пройти идентификацию других услуг

4.3 Процесс аутентификации Kerberos

В центре внимания протокола Kerberos находится вторая часть (то есть процесс аутентификации):

(1) Клиент отправляет в KDC ранее полученный TGT и информацию об услуге (название услуги и т. Д.), Которую необходимо запросить. Служба выдачи билетов в KDC генерирует ключ сеанса между клиентом и службой для службы для аутентификации клиента. Затем KDC упаковывает этот ключ сеанса с именем пользователя, адресом пользователя (IP), именем службы, периодом действия и отметкой времени в Билет (эта информация в конечном итоге используется Сервисом для аутентификации Клиента) для Сервиса, но протокол Kerberos не делает этого. Отправьте билет непосредственно в Сервис, но перешлите его Сервису через Клиента, так что есть второй шаг.

(2) В это время KDC пересылает билет только сейчас Клиенту. Поскольку этот Билет предназначен для Сервиса и не может быть просмотрен Клиентом, KDC шифрует Билет ключом между KDC и Сервисом до запуска протокола и отправляет его Клиенту. В то же время, для того, чтобы ключ был разделен между Клиентом и Сервисом (ключ сеанса, созданный KDC на первом этапе), KDC использует ключ между Клиентом и им, чтобы зашифровать Ключ сеанса вместе с зашифрованным тикетом и вернуть его клиенту.

(3) Чтобы завершить доставку билета, клиент пересылает только что полученный билет в службу. Поскольку клиент не знает ключ между KDC и службой, он не может рассчитать информацию в билете. В то же время Клиент расшифровывает полученный Сеансовый ключ, а затем упаковывает свое имя пользователя и адрес пользователя (IP) в Аутентификатор, шифрует его с помощью Сеансового ключа и отправляет его в Службу.

(4) После получения билета Сервис использует ключ между ним и KDC для дешифрования информации в билете, чтобы получить Сеансовый ключ и имя пользователя, адрес пользователя (IP), имя сервиса и срок действия. Затем используйте ключ сеанса для расшифровки аутентификатора для получения имени пользователя. Адрес пользователя (IP) сравнивается с именем пользователя и адресом пользователя (IP), расшифрованными в предыдущем билете, для проверки личности клиента.

(5) Если Сервис возвращает результат, верните его Клиенту.

4.4 Применение Kerberos на Hadoop

Используйте Kerberos для аутентификации внутри кластера Hadoop

Конкретный процесс выполнения может быть проиллюстрирован следующим образом:

4.5 Причины использования Kerberos для проверки

• Надежный Hadoop сам по себе не имеет функций аутентификации и функций создания групп пользователей и использует системы аутентификации, которые полагаются на периферию
• Эффективный Kerberos использует операцию симметричного ключа, быстрее, чем открытый ключ SSL
• Простое управление Пользователь может легко работать без сложных инструкций. Например, чтобы отменить пользователя, вам нужно всего лишь удалить его из базы данных KDC Kerbores.

5. Справочные материалы

（3）“Hadoop Security Design” Owen O’Malley, Kan Zhang, Sanjay Radia, Ram Marti, and Christopher Harrell

Оригинальная статья, пожалуйста, укажите: перепечатано сБлог Донга

Конфигурация HDFS Аутентификация Kerberos

В этой статье в основном описывается процесс настройки встроенного в HDFS Kerberos в кластере CDH Hadoop, включая инструкции по установке Kerberos и связанные с Hadoop изменения конфигурации.

нота:

Первая и вторая части ниже являются выдержками из "Практическое развертывание Hadoop Kerberos"В основном для краткого ознакомления с механизмом аутентификации Hadoop и протоколом аутентификации Kerberos. Здесь, спасибо оригинальному автору.

1. Механизм аутентификации Hadoop

Проще говоря, Hadoop без аутентификации kerberos может быть подключен, пока есть клиент. Более того, через машину интрасети с полномочиями root, создав соответствующего пользователя linux, вы можете получить соответствующие полномочия в кластере Hadoop.

После реализации Kerberos любой пользователь на любом компьютере должен иметь запись в Kerberos KDC, прежде чем разрешить связь с другими модулями в кластере.

Для получения подробной информации, пожалуйста, обратитесь кИсследование механизма безопасности Hadoop

2. Протокол аутентификации Kerberos

Kerberos — это сетевой протокол аутентификации, целью которого является предоставление мощных сервисов аутентификации для клиент-серверных приложений через ключевую систему.

При использовании Kerberos клиенту необходимо пройти три этапа для получения услуг:

• Аутентификация: клиент отправляет сообщение на сервер аутентификации и получает билет на выдачу билетов (TGT) с отметкой времени.
• Авторизация. Клиент использует TGT для запроса служебного билета с сервера предоставления билетов (TGS).
• Запрос на обслуживание: клиент представляет билет на обслуживание серверу для подтверждения его легитимности.

Для этого Kerberos требуется Центр распределения ключей (KDC) для аутентификации. KDC имеет только одного мастера и может принести несколько рабов. Ведомый компьютер выполняет только обычную аутентификацию. Изменения, внесенные в Mater, должны автоматически синхронизироваться с ведомыми.

Кроме того, KDC необходим администратор для ежедневных операций управления. Администратор может войти удаленно или локально.

3. Сборка Kerberos

3.1 Окружающая среда

Мы установили Kerberos на трехузловом сервере. Кластер hadoop был установлен на этих трех узлах. См. Процесс установки hadoop:Установите кластер Hadoop CDH, используя yum, Машины с тремя узлами распределены как: cdh1, cdh2, cdh3.

• Операционная система: CentOs 6,6
• Работающий пользователь: root

3.2 Процесс установки

3.2.1 Подготовка

Подтвердите добавление разрешения имени хоста в /etc/hosts В файле.

Примечание: пожалуйста, используйте строчные буквы для имени хоста, в противном случае при интеграции kerberos могут возникнуть некоторые ошибки.

3.2.2 Установка сервера kdc

Установите пакеты krb5, krb5-server и krb5-client на KDC (здесь cdh1).

Установите krb5-devel и krb5-workstation на других узлах (cdh1, cdh2, cdh3):

$ ssh cdh1 "yum install krb5-devel krb5-workstation -y"

$ ssh cdh2 "yum install krb5-devel krb5-workstation -y"

$ ssh cdh3 "yum install krb5-devel krb5-workstation -y"

3.2.3 Изменить файл конфигурации

Сервер kdc включает три файла конфигурации:

Одним из способов настройки Kerberos является редактирование файла конфигурации /etc/krb5.conf. Установочный файл по умолчанию содержит несколько образцов элементов.

Сбрасываем безопасный канал (пароль) между контроллерами домена

Если сломалась репликация, и пароли контроллеров домена не синхронизированы, и “secure channel is broken” то:

Для сброса пароля KDC на проблемном сервере:

1. Останавливаем службу Key Distribution Center (KDC). ( net stop KDC)

2.Запускаем Kerbtray.exe (или klist, как кому удобнее)

3. Очищаем билеты (Purge Tickets) в графике или klist -Purge. Убедитесь, что билеты удалены.

4. На PDC emulator сбрасываем пароль учетной записи проблемного контроллера домена:

netdom /resetpwd /server:server2 /userd:domain.com\administrator /passwordd:password

5. Для синхронизации изменений выполняем repadmin /syncall.

6.Запускаем службу KDC на проблемном сервере, на котором были проблемы с репликацией (Server2): net start KDC.