Изучаем принцип работы Неimdal Kerberos::Журнал СА 6.2005
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

Событие  

В банке рассола ждет сисадмина с полей фрактал-кукумбер

Читайте впечатления о слете ДСА 2024, рассказанные волонтером и участником слета

 Читать далее...

Организация бесперебойной работы  

Бесперебойная работа ИТ-инфраструктуры в режиме 24/7 Как обеспечить ее в нынешних условиях?

Год назад ИТ-компания «Крок» провела исследование «Ключевые тренды сервисного рынка 2023». Результаты

 Читать далее...

Книжная полка  

Читайте и познавайте мир технологий!

Издательство «БХВ» продолжает радовать выпуском интересных и полезных, к тому же прекрасно

 Читать далее...

СУБД PostgreSQL  

СУБД Postgres Pro

Сертификация по новым требованиям ФСТЭК и роль администратора без доступа к данным

 Читать далее...

Критическая инфраструктура  

КИИ для оператора связи. Готовы ли компании к повышению уровня кибербезопасности?

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

 Читать далее...

Архитектура ПО  

Архитектурные метрики. Качество архитектуры и способность системы к эволюционированию

Обычно соответствие программного продукта требованиям мы проверяем через скоуп вполне себе понятных

 Читать далее...

Как хорошо вы это знаете  

Что вам известно о разработках компании ARinteg?

Компания ARinteg (ООО «АРинтег») – системный интегратор на российском рынке ИБ –

 Читать далее...

Графические редакторы  

Рисование абстрактных гор в стиле Paper Cut

Векторный графический редактор Inkscape – яркий представитель той прослойки open source, с

 Читать далее...

День сисадмина  

Учите матчасть! Или как стать системным администратором

Лето – время не только отпусков, но и хорошая возможность определиться с профессией

 Читать далее...

День сисадмина  

Живой айтишник – это всегда движение. Остановка смерти подобна

Наши авторы рассказывают о своем опыте и дают советы начинающим системным администраторам.

 Читать далее...

Виртуализация  

Рынок решений для виртуализации

По данным «Обзора российского рынка инфраструктурного ПО и перспектив его развития», сделанного

 Читать далее...

Книжная полка  

Как стать креативным и востребованным

Издательский дом «Питер» предлагает новинки компьютерной литературы, а также книги по бизнесу

 Читать далее...

Книжная полка  

От создания сайтов до разработки и реализации API

В издательстве «БХВ» недавно вышли книги, которые будут интересны системным администраторам, создателям

 Читать далее...

Разбор полетов  

Ошибок опыт трудный

Как часто мы легко повторяем, что не надо бояться совершать ошибки, мол,

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 6124
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 6832
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 4117
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 2969
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 3774
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 3782
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6271
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3126
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3426
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7241
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 10609
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12330
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 13962
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9093
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 7047
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5355
Комментарии: 3
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4585
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3396
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

04.12.2013г.
Просмотров: 3122
Комментарии: 0
Паутина в облаках

 Читать далее...

03.12.2013г.
Просмотров: 3376
Комментарии: 0
Рецензия на книгу «MongoDB в действии»

 Читать далее...

02.12.2013г.
Просмотров: 2996
Комментарии: 0
Не думай о минутах свысока

 Читать далее...

Друзья сайта  

 Изучаем принцип работы Неimdal Kerberos

Архив номеров / 2005 / Выпуск №6 (31) / Изучаем принцип работы Неimdal Kerberos

Рубрика: Безопасность /  Механизмы защиты

МИХАИЛ КОНДРИН

Изучаем принцип работы Неimdal Kerberos

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

Чтобы подробнее разобраться с возникающими задачами, рассмотрим ситуацию с организацией распределенной вычислительной системы. Разумеется, чем больше компьютеров входят в кластер, тем выше его вычислительная мощность. Наиболее распространненные системы кластерных вычислений на сегодня – Parallel Virtual Machine и Message Passing Interface. Обе позволяют пользователю, в данном случае разработчику программ, пересылать куски данных, нуждающихся в обработке, между узлами кластера и синхронизировать получение результатов с разных узлов. Это фасад системы. За кулисами происходит обращение к удаленному командному интерпретатору и вызов определенных программ в нем. То есть администратору такой системы необходимо добиться, чтобы пользователи кластера имели доступ к командному интерпретатору на узлах кластера и, более того, этот доступ должен быть беспарольным для каждой пары компьютеров в кластере. Не очень-то удобна система, где запуск нескольких параллельных копий программы требует от пользователя регистрации на каждом из узлов кластера.

Таким образом, во-первых, информация о пользователях должна совпадать на всех этих компьютерах. Один из вариантов решения – иметь одинаковые копии /etc/passwd и /etc/shadow на каждом из узлов с их последующим обновлением с помощью скриптов при добавлении нового пользователя. Во-вторых, если в качестве удаленного командного интерпретатора используется rsh, то добиться беспарольного входа с помощью внесения всех компьютеров, входящих в этот кластер, в файл /etc/hosts.equiv (этот файл также должен совпадать на всех узлах кластера). Однако использование rsh гарантирует вам проблемы с безопасностью, если предположить возможность доступа к кластеру извне локальной сети, который, как вы помните, должен быть беспарольным. Можно сконфигурировать доступ по адресу компьютера (с помощью tcp-wrappers) и бороться с ip-spoofing внешними средствами или настраивать openssh в качестве удаленного командного интерпретатора. В последнем случае вам придется мириться с тем, что процессорные циклы будут расходоваться не на расчет, а на кодирование/раскодирование блоков данных. Тем не менее ни одно из этих решений нельзя считать удачным.

Далеко не каждому из вас приходится сталкиваться с настройками вычислительных кластеров. Но именно эта проблема построения распределенной вычислительной системы Athena заставила в начале 80-х годов программистов из Массачусетского технологического института разработать и внедрить протокол удаленной аутентификации пользователей. Комбинирование специальных криптографических средств позволяло, с одной стороны, свести на нет вероятность перехвата паролей и иметь шифрованный канал для передачи данных между компьютерами (эта возможность могла отключаться по желанию пользователя). А с другой – иметь систему с единой регистрацией (single sign-on), что дает возможность пользователю регистрироваться один раз при входе в систему и в дальнейшем иметь свободный доступ к сетевым ресурсам на основе этой регистрации.

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

Kerberos с точки зрения пользователя

На пользовательском уровне все реализации Kerberos выглядят однотипно, поэтому рассмотрим, как это происходит в моем случае. Регистрация в Kerberos осуществляется командой kinit, которая автоматически вызывается при моем входе на рабочую станцию под управлением Windows XP. В результате мне выдается основной документ, удостоверяющий мою личность в Kerberos, – «супербилет», билет, гарантирующий получение доступа к сетевым службам (или TGT – ticket granting ticket). При этом у меня всегда есть возможность зарегистрироваться в Kerberos под другим именем с помощью все той же команды kinit, что приводит к обновлению начального билета. Теперь предположим, что я хочу посмотреть логи на своем router/firewall под управлением Linux. Я открываю терминал cygwin. Первое, что можно сделать, – просмотреть имеющиеся билетики:

mike@alex ~$ klist

Credentials cache: FILE:/tmp/krb5cc_1017

        Principal: mike@HPPI.TROITSK.RU

 

  Issued           Expires          Principal                          

May 29 22:18:22  May 30 22:18:22  krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU

В списке, как вы видите, имеется только один билет – тот самый TGT. Credential Cache – это файл, в котором хранятся полученные мной сертификаты. По умолчанию его название – это комбинация /tmp/krb5cc_ и id пользователя. Срок действия любого билетика ограничен по времени – это снижает интерес к его перехвату со стороны злоумышленника. Теперь я запускаю командный интерпретатор на удаленном компьютере:

$ telnet -F relay

Trying 192.168.1.254...

Connected to relay.hppi.troitsk.ru.

Escape character is "^]".

Waiting for encryption to be negotiated...

[ Trying mutual KERBEROS5 (host/relay.hppi.troitsk.ru@HPPI.TROITSK.RU)... ]

[ Kerberos V5 accepts you as ``mike@HPPI.TROITSK.RU"" ]

[ Kerberos V5 accepted forwarded credentials ]

Encryption negotiated.

$klist

Credentials cache: FILE:/tmp/krb5cc_1000

        Principal: mike@HPPI.TROITSK.RU

  Issued           Expires          Principal                          

May 29 22:21:16  May 30 22:18:22  krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU

Вот пример магии Kerberos в действии – воспользовавшись моим супербилетом, Kerberos прозрачно для пользователя организует доступ к сетевому ресурсу (в данном случае он фигурирует под именем host/relay.hppi.troitsk.ru@HPPI.TROITSK.RU) и более того – telnet при помощи Kerberos автоматически шифрует весь сетевой трафик между клиентом и сервером. Список билетов при этом не меняется – ключ -F позволяет перемещать имеющиеся у меня билетики с компьютера на компьютер. Закрытие telnet-сессии автоматически очищает кэш на удаленном компьютере с помощью вызова команды kdestroy, так что вы можете не опасаться, что ваш кэш может быть использован кем-то еще. Так как супербилет по-прежнему со мной, то это позволяет мне получить доступ к другому компьютеру, серверу Kerberos.

$telnet -F kenga

Trying 192.168.1.253...

Connected to kenga.hppi.troitsk.ru.

Escape character is "^]".

Waiting for encryption to be negotiated...

[ Trying mutual KERBEROS5 (host/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU)... ]

[ Kerberos V5 accepts you as ``mike@HPPI.TROITSK.RU"" ]

[ Kerberos V5 accepted forwarded credentials ]

Encryption negotiated.

mike@kenga:~$

Точно так же я могу получить доступ к любому сетевому сервису – например, к локальному ftp-серверу.

mike@kenga:~$ ftp kenga

Connected to kenga.hppi.troitsk.ru.

220 kenga FTP server (Version 6.00+Heimdal 0.6.3) ready.

Trying GSSAPI...

Authenticated to

Authentication successful.

 

Name (kenga:mike):

S:232-Linux 2.4.25.

S:232 User mike logged in.

S:230 Password not necessary

Remote system type is UNIX.

Using binary mode to transfer files. 

 

ftp> bye

S:221 Goodbye.

Заметьте, что во всех случаях мне не потребовался ввод пароля. Доступ ко всем компьютерам мне предоставлялся на основании моего TGT. Все операции c Kerberos (выдача билетов, добавление/удаление пользователей и т. д.) фиксируются в его логах, и можете убедиться, что вся моя активность с перемещениями от компьютера к компьютеру зафиксирована в файле /var/log/krb5kdc.log. Для удобства я разделил кусок log-файла на 4 части, соответствующие процессам получения доступа к моей рабочей станции, удаленного доступа к двум серверам и серверу ftp.

2005-05-29T22:18:22 AS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU

2005-05-29T22:18:22 Using des-cbc-crc/des-cbc-md5

2005-05-29T22:18:22 Requested flags: renewable_ok, renewable, forwardable

2005-05-29T22:18:23 sending 574 bytes to IPv4:192.168.1.45

2005-05-29T22:18:23 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [renewable, forwardable]

2005-05-29T22:18:23 sending 593 bytes to IPv4:192.168.1.45

......

2005-05-29T22:21:15 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for host/relay.hppi.troitsk.ru@HPPI.TROITSK.RU

2005-05-29T22:21:16 sending 546 bytes to IPv4:192.168.1.45

2005-05-29T22:21:16 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [forwarded, forwardable]

2005-05-29T22:21:16 sending 589 bytes to IPv4:192.168.1.45

......

2005-05-29T22:21:43 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.254 for host/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU

2005-05-29T22:21:44 sending 550 bytes to IPv4:192.168.1.254

2005-05-29T22:21:44 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.254 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [forwarded, forwardable]

2005-05-29T22:21:44 sending 593 bytes to IPv4:192.168.1.254

......

2005-05-29T22:22:27 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.253 for ftp/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU

2005-05-29T22:22:27 Server not found in database: ftp/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU: No such entry in the database

2005-05-29T22:22:27 sending 145 bytes to IPv4:192.168.1.253

2005-05-29T22:22:27 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.253 for host/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU

2005-05-29T22:22:27 sending 550 bytes to IPv4:192.168.1.253

2005-05-29T22:22:28 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.253 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [forwarded, forwardable]

2005-05-29T22:22:28 sending 546 bytes to IPv4:192.168.1.253

Вы можете сказать: «Как же так – протоколы telnet и ftp небезопасны и правильнее использовать openssh. И ничего удивительного в беспарольной аутентификации нет – ту же самую функциональность обеспечивает ssh, предоставляя возможность регистрироваться по парам публичных/секретных ключей». Все правильно. Только для того, чтобы в сети из N компьютеров обеспечить доступ по ssh с любого из этих компьютеров на любой другой, вам придется в общем случае проделать 2N*{число пользователей} перемещений публичных ключей (каждая пара компьютеров в сети обменивается публичными ключами пользователей), что в случае больших сетей трудноосуществимо. В то же время с помощью Kerberos вам нужно только зарегистрировать каждый из компьютеров на сервере Kerberos и иметь один ключ на каждом из хостов (в отличие от ssh в Kerberos используется симметричное шифрование) – итого 2N операций. Что же касается первой части вопроса, то я использую специальный «керберизованный» вариант telnet, что защищает соединения между хостами не хуже, чем ssh. Главный недостаток стандартного telnet (и не только его) состоит в том, что при аутентификации на удаленном компьютере telnet пересылает пароль пользователя по сети в виде открытого текста, что позволяет злоумышленнику перехватить его. Ssh обходит эту опасность с помощью несимметричного шифрования пароля. А каким же образом Kerberos удается избегать брешей в защите связанных с удаленной аутентификацией?

Удаленная аутентификация в Kerberos

Делается это с помощью уже упоминавшихся ранее билетиков/сертификатов (tickets/credentials – оба слова используются как синонимы) – специальным образом изготовленных и упакованных шифровальных ключей. В Kerberos как пользователь, так и сетевая служба не различаются между собой и именуются principal (принципал – юридический термин, означающий лицо, поручающее агенту совершить сделку от его имени), что весьма точно описывает функции принципалов в Kerberos. Принципалы определяются своим именем и паролем, причем в случае сетевой службы в качестве этого пароля выступает ключ, хранящийся на том же компьютере, где работает защищаемый сервис. База данных принципалов хранится на сервере Kerberos, и при необходимости проверить аутентичность пользователя или сервиса, компьютеры, объединенные в сектора (realms), соединяются с этим сервером. По поводу терминологии: точный перевод «realm» («царство») применительно к Kerberos не прижился, а иногда используемый термин «домен» не кажется мне удачным, поскольку слово и так перегружено. Так же, как и в случае с DNS, главный контроллер сектора Kerberos (Key Distribution Center, KDC, центр выдачи ключей) может иметь как дополнительные, slave, контроллеры (что позволяет обеспечить бесперебойную работу при выходе из строя основного контроллера), так и в одиночку держать несколько секторов. Типичное имя принципала, например, сервиса удаленного доступа к командному интерпретатору компьютера, выглядит таким вот образом: host/kdc.myrealm.ru@MYREALM.RU, что обозначает сервис с основным именем (primary name) host и характеристикой (instance) kdc.myrealm.ru, принадлежащий сектору MYREALM.RU. Разделение имен принципалов на несколько частей позволяет различать, с одной стороны, разные службы, работающие на одном хосте (с помощью primary name, host в нашем случае). А с другой – среди нескольких однотипных служб, работающих в сети, выбирать конкретную, запущенную на определенном сервере (с помощью поля instance, которая в нашем случае совпадает с именем компьютера). Название секторa не обязано повторять доменное имя сети, но именно такое правило наименований считается устоявшейся практикой.

Теперь посмотрим, что происходит, если пользователь joeuser (а точнее, принципал joeuser@MYREALM.RU – поле instance для «живых» пользователей обычно не используется) пытается получить доступ к этому серверу. Предполагается, что как клиентская программа telnet, так и telnetd демон собраны с поддержкой Kerberos (обе эти программы входят в дистрибутив Heimdal). Разумеется, как сам сервер, так и пользователь должны быть зарегистрированы в одном и том же секторе Kerberos. Как обычно, сеанс подключения к серверу начинается с того, что пользователь запускает telnet со своим регистрационным именем и именем удаленного компьютера telnet -l joeuser kdc.myrealm.ru. Клиентская программа после этого обращается к KDC с просьбой предоставить для joeuser доступ к хосту kdc.myrealm.ru. Kerberos генерирует по определенным правилам шифровальный ключ (session key) и разыскивает по своей базе данных принципалов joeuser и host/kdc.myrealm.ru, а также их пароли (ключи). Если пароли найдены (в противном случае сеанс заканчивается аварийно – т.к. кто-то из этих двух принципалов не зарегистрирован в секторе Kerberos), Kerberos приступает к генерированию сессионного ключа (session key). С помощью ключа принципала host/kdc.myrealm.ru он шифрует сгенерированный session key вместе с именем пользователя joeuser, потом прилагает к зашифрованному блоку вторую копию того же session key и снова шифрует получившийся билетик с помощью пароля пользователя. После этого пакет отсылается клиентской программе. Если к этому времени пользователь набрал свой пароль и он совпадает с паролем, использованным Kerberos при шифровке, то клиентская программа сумеет расшифровать билетик. Далее, половина билетика (с session key) остается пользователю, а вторая, которая не может быть расшифрована клиентом, поскольку ключ сервера ей неизвестен, пересылается на сервер. Сервер расшифровывает ее с помощью своего ключа и таким образом узнает как session key, так и имя пользователя, что позволяет серверу авторизовать его своими собственными средствами. Заметим, что помимо регистрации в этом случае имеется возможность использовать полученный session key, поскольку в итоге он известен как клиенту, так и серверу, для шифрования сетевого трафика в рамках данной сессии, чем многие приложения и пользуются. Схематически процесс обмена сертификатами показан на рис. 1.

Рисунок 1. Процесс обмена сертификатами

Рисунок 1. Процесс обмена сертификатами

Что еще интересного в используемом Kerberos механизме аутентификации? Дело в том, что Kerberos оказывается еще более параноидальным, чем мы предполагали вначале, т.е. считает ненадежными не только сетевые соединения (ни один из паролей, как вы могли заметить, не передается в открытую по сети), но и клиентский, и даже серверный компьютер. Для каждого из них ключ/пароль партнера так и остается неизвестным – только session key, который для потенциального взломщика интереса не представляет, поскольку используется только в данной сессии. Как известно, безопасность и удобство пользователей вещи взаимоисключающие. Но ученым из МТИ удалось найти удачный компромисс, придумав еще одну замечательную вещь – ticket granting ticket (TGT). Если пытаться переводить этот термин на русский – «билет для выдачи других билетов», что-то вроде единого проездного. Смысл его в том, что пользователь сети проходит полностью процедуру регистрации (с вводом имени и пароля) в своем секторе только один раз, а сертификат, полученный в результате, затем используется клиентскими приложениями как эквивалент пользовательского пароля для получения доступа к сетевым сервисам. Процесс выдачи ТGT ничем не отличается от описанного выше, только в качестве службы, к которой пользователь получает доступ, выступает сам Kerberos – его Ticket Granting Service. После получения TGT записывается в кэш-файл на диске клиентского компьютера и затем по мере надобности извлекается оттуда. В схеме, описанной выше, session-key, закодированный в TGT используется вместо пароля пользователя при шифровании сертификата, предоставляемого для доступа к сетевому ресурсу. И хотя TGT хранится в кэше на диске рабочей станции пользователя, угроза, связанная с его перехватом, не столь уж серьезна, поскольку его действенность ограничена по времени. TGT позволяет организовать в корпоративной сети single sign-on (система единой регистрации) систему. Например, с помощью замены системного login на керберизованный аналог (программа с тем же именем входит в состав Heimdal Kerberos) при входе на рабочую станцию пользователь получает TGT, который затем используется для генерирования билетиков, специфичных для какой-нибудь из сетевых служб.

Таким образом, следует помнить, что при любой аутентификации в Kerberos всегда участвуют два принципала – один соответствует пользователю, пытающемуся получить доступ к сервису, а второй – самому этому сервису. Мы не будем рассматривать более сложный механизм аутентификации, так называемый user-to-user, когда сетевой сервис не имеет собственной записи в базе данных Kerberos, а использует сертификаты пользователя, запустившего сервис. Аутентификация user-to-user могла бы быть полезна, например, для X-серверов, но и для них эта методика не получила большого распространения.

Так в общих чертах выглядит принцип работы Kerberos. Многие детали реализации протокола Kerberos при этом пришлось опустить. В частности, формат сертификата в действительности более сложен, чем описано здесь. В него входит время выдачи и срок годности сертификата, адрес компьютера, на который отсылается сертификат, и флажки, позволяющие контролировать использование сертификатов и тем самым настраивать политику безопасности внутри сектора Kerberos. Скажем, с помощью снятия флажка forwardable можно «привязать» сертификат к одному компьютеру и запретить его перемещение на другие хосты. Пример, рассмотренный в начале статьи, был бы невозможен в этом случае – после получения удаленного доступа мне каждый раз потребовалось бы вводить пароль для запроса нового TGT.

В следующем номере журнала мы перейдем к практической части и развернём инфраструктуру Kerberos в локальной сети.

Приложение

История создания Kerberos

В 1983 году была начата работа по созданию системы Athena. Работу финансировали компании IBM и DEC, и в 1987 году была выпущена первая версия протокола Kerberos (Kerberos 4). Дальнейшая эксплуатация выявила недостатки протокола, и обновленный вариант Kerberos 5 вышел в свет в 1993 году. В настоящее время 4 версия практически не используется, но в реализациях протокола от МТИ совместимость с предыдущей версией продолжает сохраняться. К 1993 году протокол Kerberos уже завоевал популярность, и многие компании, разработчики программного обеспечения стремились использовать его в своих программных продуктах. Но тут имел место юридический казус – дело в том, что в то время в США еще действовали законы, введенные еще во время холодной войны, запрещающие экспорт военных технологий. Поскольку криптографическая защита, использованная в Kerberos, классифицировалась как военная технология, это создавало препятствия для использования его в программных продуктах сторонних фирм и распространения его за пределами США. Для решения этой проблемы была выпущена версия протокола Kerberos 4, из которого была изъята вся сильная криптография. Эта реализация Kerberos получила название Bones (кости), и ограничения на ее экспорт уже не действовали. В 1997 году группа программистов из Стокгольмского Королевского университета, взяв за основу Bones, проделала обратную работу и вставила недостающую криптографическую функциональность. Вот так экспортные ограничения Соединенных Штатов способствовали развитию европейского hi-tech. Впоследствии ими же была выпущена реализация протокола Kerberos 5, получившая название Heimdal. Heimdal (Хеймдалль) – это божество из скандинавского пантеона, чьи функции состояли в охране стратегических коммуникаций, а именно – моста, разделяющего Асгард и Мидгард. Так же, как и в случае с древнегреческим прототипом Kerberos, здесь эксплуатируется образ неподкупного стража. Интересно отметить, что мотивом для программистов из Стокгольмского университета, так же как и для их коллег из МТИ, являлась задача обеспечения публичного доступа к вычислительному кластеру. Последним эпизодом из истории Kerberos стало объявление компанией Microsoft в 1999 году о поддержке Kerberos в своей будущей операционной системе NT 5.0 (впоследствии названной Windows 2000), что действительно было реализовано в качестве компонента Active Directory. В настоящее время Kerberos является промышленным стандартом удаленной аутентификации пользователей.

Литература, ссылки:

  1. Гребенников Р. Танцуем Самбу. – Журнал «Системный администратор», №11, ноябрь 2004 г. – 32-38 с (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=11.2004;a=07).
  2. Фундаментальное обсуждение протокола Kerberos (на англ.) можно найти в ссылках на сайте Массачусетского технологического института: http://web.mit.edu/kerberos/www/papers.html.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-45
E-mail: sa@samag.ru