Какой хэш используется при аутентификации пользователя по протоколу kerberos
Протокол проверки подлинности Kerberos версии 5 имеет идентификатор службы проверки подлинности RPC_C_AUTHN_GSS_KERBEROS. Протокол Kerberos определяет, как клиенты взаимодействуют со службой проверки подлинности сети и были стандартизированы Целевой группе интернет-инженеров (IETF) в документе RFC 1510. Клиенты получают билеты в центре распространения ключей Kerberos и предъявляют их серверам при установлении соединений. Билеты Kerberos представляют собой сетевые учетные данные клиента.
Как и NTLM, протокол Kerberos использует доменное имя, имя пользователя и пароль для представления удостоверения клиента. Первоначальный билет Kerberos, полученный из KDC, когда пользователь входит в систему на основе зашифрованного хэша пароля пользователя. Этот начальный билет кэшируется. Когда пользователь пытается подключиться к серверу, протокол Kerberos проверяет кэш билетов на наличие действительного билета для этого сервера. Если он недоступен, первоначальный билет пользователя отправляется в KDC вместе с запросом на запрос на запрос для указанного сервера. Этот билет сеанса добавляется в кэш, и его можно использовать для подключения к тому же серверу до истечения срока действия билета.
Когда сервер вызывает CoQueryClientBlanket с помощью протокола Kerberos, возвращается доменное имя и имя пользователя клиента. Когда сервер вызывает CoImpersonateClient, возвращается маркер клиента. Такое поведение аналогично использованию NTLM.
Протокол Kerberos работает через границы компьютера. Клиентские и серверные компьютеры должны находиться в доменах, а эти домены должны иметь отношение доверия.
Протокол Kerberos требует взаимной проверки подлинности и поддерживает его удаленно. Клиент должен указать имя участника сервера, а удостоверение сервера должно точно совпадать с этим именем участника. Если клиент задает значение NULL для имени участника сервера или если имя участника не соответствует серверу, вызов завершится ошибкой.
С помощью протокола Kerberos можно использовать уровни олицетворения, олицетворения и делегата. Когда сервер вызывает CoImpersonateClient, возвращенный маркер действителен на компьютере в течение некоторого периода времени от 5 минут до 8 часов. По истечении этого времени его можно использовать только на серверном компьютере. Если сервер работает от имени активатора, а активация выполняется с помощью протокола Kerberos, срок действия маркера сервера истекает от 5 минут до 8 часов после активации.
Протокол проверки подлинности Kerberos версии 5, реализованный Windows, поддерживает маскировку.
Kerberos — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Данная модель является одним из вариантов протокола аутентификации Нидхема — Шрёдера на основе доверенной третьей стороны. [1]
Общие сведения
Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей.
Предусматривается, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы.
Протокол Kerberos может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность использования единой учетной записи пользователя для доступа к любым ресурсам области).
Протокол основан на понятии Ticket (билет).
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).
Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).
Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде.
Работая с протоколом Kerberos, необходимо, чтобы системные часы всех участвующих во взаимодействии узлов были синхронизированы.
В качестве примера реализации протокола Kerberos имеет смысл отметить доменную аутентификацию пользователей в операционных системах Microsoft, начиная с Windows 2000. [4]
Kerberos 5
Kerberos 5 является развитием четвертой версии, включает всю предыдущую функциональность и содержит множество расширений. Однако с точки зрения реализации Kerberos 5 является абсолютно новым протоколом.
Для решения данной проблемы было решено создать расширяемый протокол с возможностью использования на различных платформах на основе технологии ASN.1. Это позволило использовать в транзакциях различные типы шифрования. Благодаря этому была реализована совместимость с предыдущей версией. Кроме того у KDC появляется возможность выбирать наиболее безопасный протокол шифрования, поддерживаемый участвующими сторонами.
Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем, что KDC выдает по требованию зашифрованный TGT любому клиенту. Важность данной проблемы также подчеркивает то, что пользователи обычно выбирают простые пароли.
Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление подлинности. На данном этапе KDC требует, чтобы пользователь удостоверил свою личность прежде, чем ему будет выдан мандат.
Kerberos 5
С целью преодоления проблем безопасности предыдущей версии Джоном Колем (John Kohl) и Клиффордом Ньюманом (Clifford Neuman) была разработана 5 версия протокола, которая в 1993 году была опубликована в RFC 1510. По прошествии времени, в 2005 спецификацией начала заниматься IETF Kerberos work group. Опубликованные ими документы включают в себя:
- характеристики шифрования и контрольной суммы (RFC 3961);
- продвинутый стандарт шифрования Advanced Encryption Standard (AES) (RFC 3962);
- Kerberos 5 «The Kerberos Network Authentication Service (V5)» (RFC 4120), уточняет некоторые аспекты RFC 1510, и намерен использоваться для более подробного и четкого описания;
- новое издание GSS-API спецификации «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2.» (RFC 4121).
В июне 2006 года был представлен RFC 4556 описывающий расширение для 5-й версии под названием PKINIT (англ. public key cryptography for initial authentication in Kerberos). Данный RFC описывал, как использовать асимметричное шифрование на этапе аутентификации клиента. На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.
Недостатки и ограничения
- Единая точка отказа: требуется постоянное наличие центрального сервера. Когда сервер Kerberos падает, новые пользователи не могут войти. Это может быть устранено с помощью нескольких серверов Kerberos и резервных механизмов аутентификации.
- Kerberos имеет строгие требования к времени, что означает, что часы участников должны быть синхронизированы в заданных пределах. Мандаты имеют время жизни и, если часы клиента не синхронизированы с часами сервера Kerberos, аутентификация не будет выполнена. Конфигурация по умолчанию требует, чтобы часы расходились не боле чем на пять минут друг от друга. На практике, как правило, используются демоны Network Time Protocol для синхронизации часов у клиентов.
- Протокол администрирования не стандартизирован и зависит от конкретной реализации сервера. Смена пароля описана в RFC 3244.
- В случае использования симметричной криптографии (Kerberos может работать с использованием как симметричной, так и асимметричной (с открытым ключом) криптографии), так как все способы аутентификации управляются централизованно центром распределения ключей (KDC), эта особенность инфраструктуры аутентификации позволит злоумышленнику выдавать себя за пользователя.
- Каждый сетевой сервис, требующий смены имени хоста, должен будет обновить собственный набор ключей Kerberos. Это усложняет использование виртуального хостинга и кластеров.
- Kerberos требует, чтобы учетные записи пользователей, клиенты и пользователи услуг на сервере, все доверяли серверу Kerberos (все должны быть в одном и том же домене с Kerberos или в доменах, имеющих доверительные отношения друг с другом). Kerberos не может использоваться в случаях, когда пользователи хотят подключаться к службам от неизвестных / ненадежных клиентов, как в обычном интернете.
Содержание
Применение для централизованной аутентификации
Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании. [10]
Kerberos — сетевой протокол аутентификации, основанный на модели, представленной Нидхемом и Шредером [1] , который был разработан для обеспечения надежной аутентификации для клиент-серверных приложений с помощью использования симметричного шифрования. Свободная реализация этого протокола разработана Массачусетским технологическим институтом. Kerberos так же используется во многих коммерческих продуктах. [2]
Можно ли взломать Kerberos?
Хотя Kerberos по-прежнему является самым безопасным протоколом, его можно взломать, как и любой другой. Kerberos, долгое время выступавший в качестве отраслевого стандарта, дал хакерам достаточно времени для преодоления системы.
Хакеры нашли 5 основных способов обойти систему Kerberos, основанных на нацеливании на уязвимые системные настройки, слабые пароли или распространение вредоносного вредоносного ПО. Давайте рассмотрим каждый из 5 типов атак:
- Pass-the-ticket: этот метод создает ложный сеансовый ключ путем подделки ложного TGT. Затем хакер может представить TGT службе как действительные учетные данные. Наличие сеансового ключа позволяет этой подделке обходить все этапы проверки Kerberos, которые предшествуют этапу предоставления сеансового ключа.
- Золотой билет: этот метод подделывает билет со статусом администратора. Хакер имеет неограниченный доступ ко всему домену при использовании этого билета; доступны отдельные устройства, серверы, данные и настройки. Хакеры могут создать «золотой билет» только в том случае, если у них есть доступ к машине администратора, обычно через установленное вредоносное ПО.
- Серебряный билет: Подобно атаке Золотого билета, серебряные билеты — это поддельный билет проверки подлинности службы, который предоставляет доступ к службе. Этот метод дает меньший доступ, чем атака по золотому билету, но его также труднее обнаружить. Все взаимодействия на этом этапе являются взаимодействиями клиент / служба, что позволяет хакеру избежать мер безопасности, установленных в KDC.
- Грубая сила: самый очевидный метод, грубая форсировка, включает использование автоматического подбора паролей для ввода тысяч паролей до тех пор, пока не будет найден правильный. Для брутфорса не требуются украденные учетные данные, но его легко обнаружить из-за нечеловеческого поведения при входе.
- Вредоносное ПО с скрытым ключом бэкдора : в этом методе хакеры устанавливают скрытый ключ-ключ доступа к бэкдору в систему, чтобы позволить им войти в систему как любой пользователь в любое время в будущем. Этот метод требует ранее успешной атаки Golden Ticket Attack, поскольку эти скелетные ключи могут быть установлены только с административным доступом. Это одни из самых сложных атак для обнаружения, поскольку взлом и атака могут произойти с разницей в годы.
Запрос сервиса клиентом
Аутентификация клиента
Основные компоненты Kerberos
Аутентификация клиента
Недостатки и ограничения
- Единая точка отказа: требуется постоянное наличие центрального сервера. Когда сервер Kerberos падает, новые пользователи не могут войти. Это может быть устранено с помощью нескольких серверов Kerberos и резервных механизмов аутентификации.
- Kerberos имеет строгие требования к времени, что означает, что часы участников должны быть синхронизированы в заданных пределах. Мандаты имеют время жизни и, если часы клиента не синхронизированы с часами сервера Kerberos, аутентификация не будет выполнена. Конфигурация по умолчанию требует, чтобы часы расходились не боле чем на пять минут друг от друга. На практике, как правило, используются демоны Network Time Protocol для синхронизации часов у клиентов.
- Протокол администрирования не стандартизирован и зависит от конкретной реализации сервера. Смена пароля описана в RFC 3244.
- В случае использования симметричной криптографии (Kerberos может работать с использованием как симметричной, так и асимметричной (с открытым ключом) криптографии), так как все способы аутентификации управляются централизованно центром распределения ключей (KDC), эта особенность инфраструктуры аутентификации позволит злоумышленнику выдавать себя за пользователя.
- Каждый сетевой сервис, требующий смены имени хоста, должен будет обновить собственный набор ключей Kerberos. Это усложняет использование виртуального хостинга и кластеров.
- Kerberos требует, чтобы учетные записи пользователей, клиенты и пользователи услуг на сервере, все доверяли серверу Kerberos (все должны быть в одном и том же домене с Kerberos или в доменах, имеющих доверительные отношения друг с другом). Kerberos не может использоваться в случаях, когда пользователи хотят подключаться к службам от неизвестных / ненадежных клиентов, как в обычном интернете.
Сервер аутентификации
Сервер аутентификации — это первая остановка при аутентификации с помощью Kerberos. Сначала клиент должен аутентифицироваться в AS, используя имя пользователя и пароль для входа.
После этого AS перенаправляет имя пользователя в KDC, который, в свою очередь, предоставляет TGT. Без выполнения этого первого шага клиент не сможет взаимодействовать с какой-либо другой частью системы Kerberos.
Что изучать дальше
Поздравляю! Сегодня вы узнали, что такое Kerberos, для чего он используется и какие шаги необходимо предпринять для аутентификации действий.
Поскольку все больше компаний используют протоколы безопасности Kerberos, чем когда-либо прежде, это понимание откроет двери для новых карьерных путей и возможностей трудоустройства. Следующие шаги на вашем пути:
Использование и распространение
Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD. В настоящее время множество ОС поддерживают данный протокол, в число которых входят: Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в RFC 3244 «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ RFC 4757 описывает использование RC4 Kerberos в Windows; различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США (англ.) [5] .
История создания
Kerberos был создан MIT в качестве решения проблем с безопасностью сети. Протокол Kerberos использует стойкую криптографию, так что клиент может идентифицироваться на сервере (и обратно) через незащищенное сетевое соединение. Kerberos это и имя сетевого протокола аутентификации и общий термин для описания программ, где он реализован (например, Kerberos telnet). Доступно несколько свободных реализаций этого протокола, работающих на множестве операционных систем. Massachusetts Institute of Technology (MIT), где Kerberos был первоначально разработан, продолжает разрабатывать собственный пакет Kerberos. Он обычно использовался в США как криптографический продукт, и в этом качестве попадал под действие ограничений на экспорт. MIT Kerberos доступен в виде порта (security/krb5). Heimdal Kerberos это другая реализация версии 5, которая разрабатывалась исключительно вне США для обхода экспортных ограничений (и поэтому часто включалась в некоммерческие реализации UNIX(R)). Heimdal Kerberos доступен в виде порта (security/heimdal), его минимальный комплект включен в базовую установку FreeBSD. [2]
Авторизация клиента
Билет на выдачу билетов
Этот билет выдается KDC после успешной аутентификации клиента. TGT зашифрован и содержит разрешения на то, к каким службам может получить доступ клиент, как долго предоставляется доступ, а также ключ сеанса, используемый для связи с клиентом.
Клиенты не могут расшифровать TGT, так как у них нет ключа TGS. Следовательно, они должны слепо представить TGT желаемым службам (которые могут получить доступ к TGS) и позволить службам решить, может ли клиент получить к нему доступ.
Скрывая TGT от клиента, Kerberos предотвращает мошенническое копирование или изменение разрешений клиентом.
Ранние версии
Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.
Развитие протокола
Аутентификация клиента
Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения мандатов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:
- Идентификатор клиента, его метка времени и идентификатор сервера.
- Сессионный ключ Клиент/TGS, идентификатор TGS и время жизни мандата, зашифрованные секретным ключом клиента.
- TGT (который включает идентификатор и сетевой адрес клиента, метку времени KDC, период действия мандата и сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.
Запрос сервиса клиентом
- Зашифрованный мандат сервиса полученный ранее.
- Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.
- Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.
Клиент расшифровывает подтверждение, используя сессионный ключ клиент/сервис и проверяет, действительно ли метка времени корректно обновлена. Если это так, то клиент может доверять серверу и может начать посылать запросы на сервер.
Сервер предоставляет клиенту требуемый сервис. [6]
Настройка Kerberos 5
Настройка клиента Kerberos 5 выполняется гораздо проще, чем настройка сервера. Как минимум, вы должны установить пакеты клиента и сформировать для своих клиентов правильный файл конфигурации krb5.conf. Версии rsh и rlogin, поддерживающие Kerberos, также потребуют некоторых изменений в конфигурации.
1.Убедитесь в том, что между клиентом Kerberos и KDC время синхронизировано. За дополнительной информаций обратитесь к разделу Настройка сервера Kerberos 5. Помимо этого, до установки на компьютере клиентских программ Kerberos необходимо убедиться в корректной работе DNS.
2.Установите пакеты krb5-libs и krb5-workstation на всех клиентских компьютерах вашей сферы. Вы должны поместить собственную версию файла /etc/krb5.conf на клиентские компьютеры; обычно это тот же файл krb5.conf, что и на KDC.
3.До того как определённая рабочая станция в вашей сфере позволит пользователям подключиться, используя rsh и rlogin, использующие Kerberos, на этом компьютере необходимо установить пакет xinetd, и создать для него собственную запись узла в базе данных Kerberos. Серверным программам kshd и klogind также понадобится получить ключи своих учётных записей служб.
Воспользовавшись kadmin добавьте учётную запись компьютера для этой рабочей станции. Именем экземпляра в этом случае будет имя рабочей станции. Так как вам никогда больше не понадобится вводить пароль для этой учётной записи, и вероятно, вы не будет против сильного пароля, воспользуйтесь параметром -randkey команды addprinc для программы kadmin для создания учётной записи и присвоения ей случайного пароля:
Обратите внимание, после создания учётной записи, вы можете извлечь ключи рабочей станции, выполнив команду kadmin на самой рабочей станции и воспользовавшись командой ktadd в kadmin:
Чтобы использовать версии rsh и rlogin, поддерживающие Kerberos, вы должны включить klogin, eklogin и kshell.
4.Также может понадобиться запуск других сетевых служб, поддерживающих Kerberos. Чтобы использовать telnet с поддержкой Kerberos, вы должны включить krb5-telnet. Чтобы предоставить FTP доступ, создайте и извлеките ключ для учётной записи корня ftp, указав в качестве экземпляра имя FTP сервера. Затем включите gssftp. Сервер IMAP, включенный в пакет imap, будет использовать проверку подлинности GSS-API с Kerberos 5, если найдёт соответствующий ключ в /etc/krb5.keytab. Корнем для учётной записи должен быть imap. Служба CVS gserver использует учётную запись с корнем cvs и во остальном совпадает с . pserver. [8]
Kerberos 4
Kerberos 4 в значительной степени основан на протоколе Нидхема-Шрёдера, но с двумя существенными изменениями.
Как результат, протокол Kerberos 4 содержит два логических компонента:
- Сервер аутентификации (сокр. СА, англ. Authentication Server, сокр. AS)
- Сервер выдачи мандатов или разрешений (англ. Ticket Granting Server, сокр. TGS).
В случае удачной проверки СА генерирует случайный сеансовый ключ, который будет совместно использоваться клиентом и TGS (данный ключ защищает дальнейшие запросы мандатов у TGS на другие сервисы). KDC создает 2 копии сессионного ключа: одну для клиента и одну для TGS.
Детали последнего шага — отправки мандата службы серверу приложений — не стандартизировались Kerberos 4, поэтому его реализация полностью зависит от приложения.
Использование и распространение
Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD.
В настоящее время множество ОС поддерживают данный протокол, в число которых входят:
- Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ описывает использование RC4 Kerberos в Windows;
- различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США. [9]
Уязвимости
Шифр DES может быть использован с Kerberos, однако он больше не является Интернет-стандартом, так как он является уязвимым. [4] Уязвимости, однако, существуют во многих продуктах, использующих Kerberos, которые не были обновлены для замены DES на более новые шифры, такие как AES, например.
Kerberos — сетевой протокол аутентификации, основанный на модели, представленной Нидхемом и Шредером [1] , который был разработан для обеспечения надежной аутентификации для клиент-серверных приложений с помощью использования симметричного шифрования. Свободная реализация этого протокола разработана Массачусетским технологическим институтом. Kerberos так же используется во многих коммерческих продуктах. [2]
Центр распространения ключей
Что такое Kerberos?
Kerberos — это протокол проверки подлинности компьютерной сети, предназначенный для упрощения и безопасности проверки подлинности.
Основная идея Kerberos вращается вокруг использования локальной формы личной идентификации, называемой билетами, которые предоставляются сервером аутентификации. Каждый билет принадлежит определенным областям, которые определяют, к каким службам он предоставляет доступ. Эти билеты зашифрованы, и для их использования требуется несколько уровней дешифрования. Эта система билетов гарантирует, что конфиденциальная информация, такая как пароли, никогда не будет отправлена по сети.
Протокол Kerberos получил широкое признание с момента его создания в Массачусетском технологическом институте в 1980-х годах. Теперь он встроен в бесчисленное количество зависимых от безопасности реализаций в Интернете, и почти все компании ежедневно взаимодействуют по крайней мере с одной системой Kerberos.
Наиболее известное использование Kerberos — это Microsoft Active Directory, служба каталогов по умолчанию, включенная в Windows 2000 и более поздних версий для управления доменами и аутентификации пользователей.
Другие известные применения — Apple, НАСА, Google, Министерство обороны США и университеты по всей территории Соединенных Штатов.
Преимущества Kerberos
Kerberos так широко используется из-за его простоты и непревзойденной безопасности данных. Вот лишь некоторые из его преимуществ:
- Взаимная аутентификация: в Kerberos оба конца связи должны быть аутентифицированы, прежде чем соединение будет разрешено. Взаимная аутентификация резко снижает возможность мошенников обманным путем заставить системы отправлять конфиденциальную информацию.
Принцип работы
Kerberos 4
Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией, распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределённым системам (например, AFS) использовали идеи Kerberos 4 для своих систем аутентификации. Основными разработчиками данной версии были Стив Миллер (Steve Miller) и Клиффорд Ньюман (Clifford Neuman). Основы того, что должно было стать Kerberos 4, были описаны в техническом плане «Афина», а окончательный вариант был закреплён в исходном коде эталонной реализации, опубликованной MIT. Однако из-за ограничений на экспорт программного обеспечения, использующего шифрование, наложенных американским правительством, Kerberos 4 не мог быть распространён за пределами Соединённых Штатов. Так как Kerberos 4 при шифровании использовал алгоритм DES, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из неё весь код, касающийся шифрования. Данные меры позволили обойти ограничение на экспорт. Позже Эррол Янг (Errol Young) в Университете связи Австралии (Bond University of Australia) добавил в эту версию собственную реализацию DES. Она называлась «E-Bones» (сокращение от «encrypted bones») и могла свободно распространяться за пределами США. В 2006 году было объявлено о прекращении поддержки Kerberos 4.
Авторизация клиента на TGS
Для запроса сервиса клиент формирует запрос на TGS (TGS_REQ) содержащий следующие данные:
- TGT, полученный ранее и идентификатор сервиса.
- Аутентификатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Клиент/TGS.
После получения TGS_REQ, TGS извлекает из него TGT и расшифровывает его используя секретный ключ TGS. Это дает ему Сессионный Ключ Клиент/TGS. Им он расшифровывает аутентификатор. Затем он генерирует сессионный ключ клиент/сервис и посылает ответ (TGS_REP) включающий:
- мандат сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата и Сессионный Ключ клиент/сервис) зашифрованный секретным ключом сервиса.
- Сессионный ключ клиент/сервис, идентификатор сервиса и время жизни мандата, зашифрованные на Сессионном Ключе Client/TGS.
Содержание
Разбивка процесса Kerberos (16 шагов)
Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:
1. Войти
Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.
2. Запросы клиентов на сервер выдачи билетов
- введенное имя пользователя
- название запрашиваемой услуги
- сетевой адрес пользователя
- как долго они запрашивают доступ на
3. Сервер проверяет имя пользователя.
Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.
4. Выдача билета. Билет возвращается клиенту.
- Message A может быть расшифрован с помощью секретного ключа клиента, созданного на шаге 1. Он содержит имя TGS, временную метку, время жизни билета и вновь предоставленный сеансовый ключ сервера предоставления билетов.
- Message Bявляется билетом на выдачу билета и может быть расшифрован только с помощью секретного ключа TGS. Он содержит ваше имя пользователя, имя TGS, метку времени, ваш сетевой адрес, время жизни билета и тот же ключ сеанса TGS.
5. Клиент получает сеансовый ключ TGS.
Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.
6. Клиент запрашивает доступ к службе с сервера
7. Сервер проверяет службу.
Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.
8. Сервер получает сеансовый ключ TGS.
Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.
Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.
9. Сервер генерирует служебный сеансовый ключ.
10. Клиент получает ключ сеанса обслуживания.
Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.
11. Клиент связывается с Сервисом
12. Расшифровка сервисов Message G
Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.
13. Сервис проверяет запрос
Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.
14. Сервис аутентифицируется для клиента.
Затем служба отправляет message Iзашифрованные с помощью сеансового ключа службы, хранимого как службой, так и клиентом. Message I- аутентификатор, содержащий идентификатор службы и временную метку.
15. Клиент проверяет услугу.
Затем клиент расшифровывает, message Iиспользуя ключ сеанса службы, кэшированный с шага 10. Затем клиент проверяет идентификатор и временные метки, содержащиеся в нем. Если оба соответствуют ожидаемым результатам, услуга считается безопасной.
16. Свободное общение между клиентом и службой
Уверенный в том, что и клиент, и служба взаимно аутентифицированы, Kerberos позволяет клиенту связываться со службой.
Пример процесса Kerberos
Каждый из этих этапов состоит из нескольких этапов, но в режиме реального времени процесс происходит очень быстро. Чтобы поместить то, что мы узнали выше, в контекст, давайте рассмотрим пример из реальной жизни.
В начале рабочего дня вы вводите пароль в свой клиент. Пароль аутентифицируется AS, а затем KDC предоставляет вам TGT. В этом билете есть набор ключей от dataScienceкоролевства.
Затем TGT кэшируется на вашем компьютере для дальнейшего использования. Этот доступ позволяет вам использовать любые услуги в dataScienceобласти, например, доступ к покупательскому поведению клиентов.
Затем вы можете получить доступ к этой службе в любое время без необходимости каждый раз аутентифицировать свои разрешения. Однако, если вы попытаетесь получить доступ к любой из служб из financesобласти, вам будет отказано, потому что ваш TGT не имеет ключей к этой области.
В конце рабочего дня срок действия вашего TGT истекает, и вы не сможете снова получить доступ к этим службам, пока не получите новый билет при входе в систему на следующий день.
Как работает Kerberos?
- Пользователь вводит имя и пароль на клиентской машине.
- Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя.
Служба выдачи билетов
Служба предоставления билетов действует как привратник между клиентами, владеющими TGT, и различными службами в сети. Когда клиент хочет получить доступ к услуге, он должен представить свой TGT в TGS.
Затем TGS аутентифицирует TGT и устанавливает сеансовый ключ, совместно используемый сервером и клиентом. Если TGS подтверждает, что клиентский TGT включает доступ к желаемой службе, клиенту предоставляется доступ для запроса услуги.
Описание протокола
Протокол подробно описан ниже.
- Пользователь вводит имя пользователя и пароль на клиентской машине. Также разрешается использовать другие механизмы, такие как PKINIT (RFC 4556), позволяющий использовать открытые ключи вместо паролей.
- Клиент преобразует пароль в ключ симметричного шифра. Для этого используется либо встроенный генератор ключей, либо односторонний хэш в зависимости от используемого криптографического набора.
Содержание
Как работает Kerberos?
Проверка подлинности Kerberos состоит из 4 этапов, в зависимости от того, какие компоненты взаимодействуют между собой:
Описание протокола
Протокол подробно описан ниже.
- Пользователь вводит имя пользователя и пароль на клиентской машине. Также разрешается использовать другие механизмы, такие как PKINIT (RFC 4556), позволяющий использовать открытые ключи вместо паролей.
- Клиент преобразует пароль в ключ симметричного шифра. Для этого используется либо встроенный генератор ключей, либо односторонний хэш в зависимости от используемого криптографического набора.
Терминология Kerberos
- Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
- Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
- Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
- Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
- Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM. [3]
Пример взаимной аутентификации:
Пользователь в сети, использующий Kerberos, может пройти аутентификацию на почтовом сервере, чтобы доказать, что он тот, за кого себя выдает. С другой стороны, почтовый сервер также должен подтвердить, что он действительно является почтовым сервером, а не какой-либо другой службой в сети, претендующей на роль почтового сервера. Если обе стороны аутентифицированы, соединение устанавливается.
Авторизация клиента
Уязвимости
Шифр DES может быть использован с Kerberos, однако он больше не является Интернет-стандартом, так как он является уязвимым. [4] Уязвимости, однако, существуют во многих продуктах, использующих Kerberos, которые не были обновлены для замены DES на более новые шифры, такие как AES, например.
Изучение
Протокол безопасности Kerberos стал основой современной кибербезопасности. Фактически, он настолько хорошо интегрирован, что большинство пользователей или даже разработчиков вообще забывают о нем. Этот скрытый статус может затруднить получение информации о том, что такое Kerberos и как он работает, особенно со всеми различными формами, которые этот протокол принимает сегодня.
В этой статье мы ответим, что такое Kerberos, как он работает, и рассмотрим типичные атаки, которые инженеры безопасности Kerberos должны преодолевать ежедневно.
К концу вы получите новую оценку современной сетевой безопасности и, надеюсь, пик интереса к кибербезопасности!
Запрос сервиса клиентом
Читайте также: