ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.12.2023
Просмотров: 45
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Содержимое поля flags имеет длину равную 32 битам и соответственно флаги этого поля имеют логический тип данных, true или falser (1 или 0 соответственно) Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Для администратора сервера Kerberos интерес представляют основные 5 флагов приведенные в таблице ниже.
Таблица 2 – Флаги мандата
| Флаг | Описание |
| FORWARDABLE | Данный флаг свидетельствует о том, что на основании этого TGT мандата TGS может генерировать новый TGT мандат с иным сетевым адресом. (флаг содержится только в TGT мандатах). |
| FORWARDED | Флаг FORWARDED указывает на то, что данный TGT мандат был переадресован или сгенерирован Указывает на то, что данный TGT мандат был переадресован или генерирован на основе другого TGT мандата. |
| PROXY | Данный флаг свидетельствует о том, что сетевой адрес, указанный в данном мандате отличается от адреса, в TGT мандате, на основании которого он сгенерирован. |
| RENEWABLE | Разрешается периодическое обновление времени действия мандата сервером выдачи мандатов. Используется в сочетании с информацией, содержащейся в поляк endtime и renew-till. |
| INITIAL | Указывает на первичность данного мандата на выдачу мандатов. Поле содержится только в TGT мандатах, полученных от сервера аутентификации AS. |
| PRE-AUTHENT | Флаг предварительной аутентификации указывает на то, что перед выдачей мандата AS сервер уже аутентифицировал клиента. В протоколе версии MIT предварительная аутентификация осуществляется по шифрованной метке даты-времени. |
| MAY-POSTDATE | Сообщает KDC о том, что на основании этого мандата на выдачу мандата может быть выдан отсроченный или недействительный сеансовый мандат. При получении клиентом от AS сервера TGT мандата с данным флагом, то в дальнейшем он может использоваться такой мандат для запроса мандата с флагами POSTDATED или INVALID |
| POSTDATED | Указывает на то, что данный мандат просрочен. |
| INVALID | Указывает на недействительность мандата в данный момент времени и на необходимость подтверждения в TGS перед использованием. Использование этого флага может быть полезно при выполнении длинных пакетных заданий на сервере, которые периодически требуют мандат. Клиент сразу может получить требуемое количество мандатов для соответствующего сеанса с распределенными значениями времени, при чем все мандаты кроме первого недействительны. Если в ходе выполнения пакетного задания наступает момент времени, когда необходим новый мандат, клиент подтверждает в TGS следующий подходящий по времени мандат. При реализации такой схемы клиенту нет необходимости повторно использовать TGT мандат для запроса сеансового мандата. |
2.2 Ограничение доступа к данным мандата
Необходимость в знании клиентом некоторой части информации, содержащейся в как в обычных сеансовых мандатах так и TGT мандатах обусловленна необходимость управления своей кэш-памятью удостоверений. Клиенту необходимо знать часть информации, содержащейся как в обычных мандата, так и в TGT мандатах, чтобы управлять своей кэш-памятью удостоверений. Когда центр распределения ключей, при помощи подпротоколов AS Exchange или TGS Exchange, возвращает мандат и сеансовый ключ, упаковывая клиентскую копию сеансового ключа в блок данных, где уже могут быть заполнены паля authtime, endtime, flags, renew-till, starttime, причем вся эта структура шифруется при помощи долговременного ключа клиента и включается в пакет KRB_AS_REP или KRB_TGS_REP и направляется на рабочую станцию клиента.
2.3 Срок «жизни» мандата
Промежуток времени в течении которого клиент, которому выдан мандат, может неограниченное количество раз предоставлять его для получения доступа к службе называется сроком действия мандата. В нем прописывается время начала и конца его «жизни». Этот механизм ограничения максимального срока действия мандата позовляет администратору ограничивать время «жизни» мандата в целях уменьшения риска компрометирования мандата или сеансового ключа. Этим временные рамки являются элементами политики безопасности Kerberos.
Когда клиент запрашивает в центре распределения ключей мандат на доступ к службе, он имеет возможность указать конкретное время начала его действия. Если он этого не сделал или попытался указать время, которое по системным часам сервера KDC уже прошло, то KDC указывает в поле starttime свое текущее системное время. При этом независимо от того указал ли время начала действия мандата пользователь или KDC, запрос обязательно должен содержать в себе время прекращения его срока действия. При получении такого запроса служба KDC прописывает значние поля endtime суммируя наибольший срок дейтсвия мандата, беря этот параметр из политики безопасности Kerberos, со значением поля starttime. Для этого она суммирует наибольший срок действия мандата, предусмотренный политикой Kerberos, со значением поля starttime, а затем проводит сравнение полученного результата со временем прекращения действия мандата, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше.
В течении сеанса связи клиент никак не уведомляется службой KDC о скором истечении срока действия сеансового мандата или TGT мандата. Не отслеживает она и транзакции сервера с клиентом, исключая краткосрочные записи, основная цель которых – предотвратить «атаку повторного воспроизведения», то есть повторное использование перехваченных пакетов. Если при попытке подключения к сервере клиент передаст просроченный сеансовый мандат, то в ответ он увидит сообщение об ошибке. В таком случае клиенту придется повторно обращатсья в KDC за новым сеансовым мандатом, при этом после проведения процедуры аутентификации подключения надобность в отслеживании срока жизни мандата отпадает, поскольку эта информация нужна лишь для подключения к серверу. При истечении срока действия сеансового мандата в ходе самого сеанса – ничего, что заметил бы пользователь не произойдет, на ход текущих операций это никак не скажется.
В том случае если клиент включает просроченный TGT мандат в свой блок запроса на сеансовый мандат, центр распределения ключей отправит клиенту сообщение об ошибке, после чего клиенту потребуется запросить новый TGT мандат, для чего ему будет необходим долговременный ключ клиента. В случае если такогой ключ, в процессе первичнйо регистрации, не был занесен в кэш-память, система попросит пользователя ввести свой пароль еще раз и на основании него сгенерирует долговременный ключ.
2.4 Обновляемые TGTмандаты
Один из элементов защиты сеансовых ключей это частая их смена. В настройках политики Kerberos предусматривается относительно небольшой срок жизни сеансовых мандатов. Есть иной способ и заключается он в использовании обновляемых мандатов. Таким образом получается использовать переодическое обновление сеансовых ключей без нужды запрашивать новый сеансовый мандат. При условии, что настрйоками политики Kerberos разрешено применение обновляемых мандатов, то центр KDC в каждый генерируемый мандат включает флаг RENEWABLE и два срока жизни мандата – первый из них ограничевает срок действия текущего экземпляра мандата, а второй определяет в течении какого времени этот мандат может быть обновлен. Поле endtime описывает срок действия текущего экземпляра мандата. Как и в случае с необновляемыми мандатами, значение вышеуказанного поля равняется сумме значения из поля starttime и
значения наибольшего срока действия мандатов, установленного политикой Kerberos. При использовании обновляемого мандата, клиент предоставляет в центр KDC обновляемый мандат для его обновления до времени указанного в поле endttime. Одновременно с ним в KDC направляется и новый аутентификатор. Получив мандат, который следует обновить, центр KDC проверяет общий срок его жизни, указанный в поле renew-till, заданным при первоначальной генерации мандата. То есть если время, указанное в поле renew-till еще не наступило, то центр KDC генерирует новый экзмемпляр мандата, где меняется сеансовый ключ и сдвигается время endtime. Такие возможности дают администратору инструменты для предусмотрения в политике Kerberos достаточно частое обновление мандатов. Частая смена сеансовых ключей в процессе обновления мандатов резко снижает риск их компрометирования, при этом администратор так же может установить наоборот, довольно длительный «срок годности» мандата – неделю, месяц или больше. По истечении этого срока мандат полностью приходит в негодность и обновлению не подлежит.
2.5 Делегирование аутентификации
Использование протокола Kerberos в многоуровневых клиент-серверных информационных системах сопряженно с определенным сложностями. Так, клиент может подключаться к серверу, который подключается к серверу более высокого уровня. Для этого первому серверу понадобится мандат на подключение ко второму, причем такой мандат должен ограничивать доступ первого сервера ко второму лишь тем функционалом, на который клиент имеет права. Для этого в протоколе предусмотрен специальный механизм под названием «делегирование аутентификации». Упрощенно, клиент разрешает серверу № 1 провести свою аутентификацию для сервера № 2. Для этого он уведомляет центр распределения ключей о том, что данный конкретный сервер имеет право представлять клиента.
Делегирование аутентификации реализуется двумя способами. Во-первых, клиент получает мандат на подключение к серверу высшего уровня, а затем передает его ближайшему серверу. Мандаты, полученные таким образом называются представительскими или proxy мандатами. Основное препятствие для реализации первого варианта — это необходимость клиенту знать имя сервера высшего уровня. Для преодоления этого препятствия и существует второй способ делегирования аутентификации. В этом случае клиент передает на ближайший сервер свой TGT мандат, который тот использует для запроса своих мандатов. TGT мандаты полученные по удостоверению клиента называются передаваемыми (forwarded). Политикой Kerberos определяется какой из вышеописанных способов будет использоваться.
2.6 Известные уязвимости
Основная критическая уязвимость, просуществовавшая, представьте себе, аж 21 год получила поэтическое название «Лира Орфея» (Orpheus’ Lyre). Согласно всё той же греческой мифологии Аполлон подарил Орфею лиру, звуки которой обладали чудесными свойствами: с помощью неё возможно было укрощать диких животных, перемещать горы и леса. Более того её звуки способны были усыплять трёхглавого пса Цербера, охраняющего вход в Аид, в честь которого и назван протокол.
Рассматриваемая уязвимость на самом деле явила себя еще в 1996 году, но описана публично и закрыта только в июле 2017 года. Лира Орфея затрагивает две из трех реализаций протокола: Microsoft Kerberos для операционных систем семейства Windows и Heimdal Kerberos для *nix-based систем, включая MacOS. Оригинальная реализация Массачусетского технологического университета не подвержена уязвимости. Уязвимость была обнаружена исследователями безопасности Джеффри Альтманом (Jeffrey Altman), Виктором Духовны (Viktor Duchovni) и Нико Вильямсом (Nico Williams). Согласно их объяснениям, найденная ошибка всего в двух строчках кода может быть использована злоумышленником, находящимся в позиции «man-in-the-middle» для хищения полномочий и повышения с их помощью привилегий для обхода шифрования, используемого в Kerberos. «Изначальным криптографическим пороком» протокола, по словам исследователей, было обилие открытого незашифрованного текста в мандатах, из которого злоумышленником могут извлекаться метаданные для последующего использования в атаке. То есть, до исправления уязвимости, в своей работе Kerberos системы метаданные извлекались не из аутентифицированного и зашифрованного блока данных отклика KDC, а из не аутентифицированного открытого текста. Таким образом атакующий в позиции человека-по-середине (между клиентом и сервером) может выдать себя за некую службу для клиента.
Для более подробного описания уместно будет привести пример из жизни, к примеру, возьмем билет на самолет. Есть у нас билет до Москвы, где пункт назначения четко пропечатан, но при предъявлении при регистрации на рейс на Хабаровск я настаиваю, что в билете пункт назначения – аэропорт города Хабаровска. И сотрудник на стойке регистрации мне верит. Так и программное обеспечение Kerberos в функции _krb5_exctract_ticket() получает значение имени службы и домена в KDC-REP из незашифрованной части мандата kdc_rep.ticke.sname и kdc_rep.ticket.realm, а должно из шифрованной части ent_part (encrypted part).