Система єдиного входу в мережу на основі протоколу Kerberos

731 Загальні відомості про протокол Kerberos

Протокол Kerberos є універсальним протоколом Аутентиф-

ції, заснованим на розподілі симетричних ключів шифрування неко-

менту, котрим довіреною сервером Протокол Kerberos є відкритим стандар-

тому і описаний в документі RFC 1510

За допомогою протоколу Kerberos розподіляються криптографічні ключі в деякій області (Realm), яка має строковий ідентифікатор, як правило, збігається з імям DNS-домену Наприклад, для компьюте-рів DNS-домену examplecom можна визначити область Kerberos EXAMPLECOM (Імя області завжди великими літерами)

Кожна обліковий запис в системі Kerberos називається сутністю (Prin-cipal), причому облікові записи існують не тільки для користувачів, але і

для кожного сервісу Імя облікового запису має наступний вигляд:

«User @ REALM» (де user – імя користувача, а RELAM – імя області)

Наприклад, імя облікового запису користувача root з домену «examplecom» –

«root@EXAMPLECOM»

Облікові записи сервісів мають вигляд / @ REALM, де

name1 – як правило, імя сервісу, а name2 – повне DNS-імя компютера

Наприклад, «HTTP / ws-linuxexampelcom @ EXAMPLECOM» Важливо відзначити,

що імена сутностей Kerberos чутливі до регістру

Рис 76 Аутентифікація по протоколу Kerberos

Інформацію про всі облікових записах, а також їхдовготривалі ключі (У разі користувача це, наприклад, хеш його пароля, тобто ключ, кото-рий буде дійсний не менше місяця) зберігаються на спеціальному сервері, званому центром розподілу ключів (Key Distribution Centre – KDC) Коли у користувача зявляється необхідність у використанні деякого сервісу, то він звертається до центру розподілу ключів із запитом коротко-

тимчасового сеансового ключа KDC повертає ключ у двох варіантах – один зашифрований довготривалим ключем користувача, другий зашифрований довготривалим ключем сервісу Відповідь KDC називається квитком, Оскільки крім ключа містить і деяку додаткову інформацію Після цього користувач самостійно пересилає квиток сервісу, і у них появля-ється певний загальний секрет, який вже можна використовувати як для ау-тентіфікаціі, так і для захисту каналу (рис 76)

Застосування довіреної сервера, який зберігає секрети всіх своїх користувачів, дає можливість обійтися без асиметричних алгоритмів

шифрування, що робить протокол Kerberos більш легким у реалізації та управлінні

На наведеній схемі видно, що кожен сервіс має зберігати собст-

венний довготривалий ключ У Unix-системах ключі сервісів зберігаються в так званому keytab-файлі (зрозуміло, що даний файл не повинен бути дос-тупен для читання всім користувачам), в ОС Windows ключ зберігається в ло-кальной базі облікових записів SAM (стандартними засобами переглянути інформацію про ключ неможливо)

Довготривалий ключ користувача, як уже згадувалося вище, –

це, наприклад, деяка хеш-функція його пароля Таким чином, в приве-денной вище схемою користувач все одно повинен вводити свій пароль при зверненні до чергового сервісу Для забезпечення реальної можливості одноразової аутентифікації схема взаємодії клієнта, сервера і KDC реально дещо відрізняється від наведеної на рис 76 У процесі аутен-тіфікаціі при вході в мережу користувач отримує спеціальний квиток, званихticket  granting  ticket  (TGT), Що використовується для аутентифікації користувача в KDC (рис 77)

Отримані користувачем квитки зберігаються в спеціальному захисту пра-

щенном кеші (у разі Unix-систем це файл, доступ до якого має тільки користувач, який отримав квиток, в Windows – це захищене сховище

модуля SSPI, тобто оперативна память) При необхідності квиток може пе-

реместіться на інший компютер (наприклад, якщо користувач відкрив сеанс по SSH або RDP), але при цьому дійсним він залишиться тільки в тому

випадку, якщо в ньому присутній спеціальний прапор (відповідно, на KDC

можна задавати, які з користувачів будуть отримувати цей прапор у квитку, а які ні)

З викладеного вище механізму випливає, що KDC НЕ аутентифікує клієнта перед самим собою Аутентифікація є тільки неявна – чи зміг клієнт скористатися тим сеансовим ключем, який він отримав, чи ні

Це створює дві проблеми: по-перше, зловмисник може отримати квиток користувача і за якийсь час витягти сеансовий ключ (наприклад, якщо застосовувався слабкий алгоритм шифрування) по-друге, зловмисник мо-

жет запросити TGT і після намагатися зламати довготривалий ключ користу-

вателя

Рис 77 Механізм одноразової аутентифікації за допомогою допоміжного квитка

TGT

Першою проблеми насправді не існує, оскільки квиток Kerbe-ros містить інформацію про свій час життя (за замовчуванням 8 годин) Тому до того часу, коли зловмисник зможе витягти сеансовий ключ, останній виявиться вже недійсним

Друга проблема вирішується за допомогою механізму преаутентіфкаціі

Даний механізм не зафіксований у RFC 1510, тобто кожен виробник може додавати свої механізми, однак наведений один варіант, який найбільш широко поширений в даний час – це преаутентіфікація по мітках часу Працює даний механізм наступним чином: клієнт у своєму запиті, в спеціальному розділі пакета Kerberos, відправляє зашифруйте-ванну своїх довготривалих ключем мітку часу, сервер расшіфрови-кість цю мітку часу і звіряє її зі своїм поточним часом Якщо разні-ца не перевищує деякого порогового значення (за замовчуванням 3 хвилини), то вважається, що клієнт пройшов преаутентіфкацію, і йому можна видавати

квиток Зрозуміло, що даний механізм вимагає синхронізації часу між усіма клієнтами Kerberos і всіма KDC

Джерело: Андрончик А Н, Богданов В В, Домуховскій Н А, Коллеров А С, Синадський Н І, Хорьков Д А, Щербаков М Ю, Захист інформації в компютерних мережах Практичний курс

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*