1. Ідентифікація та аутентифікація
2. протокол Kerberos

Анотація: У даній лекції розглядаються технічні заходи підвищення захищеності систем. В теоретичній частині вивчаються методи, що лежать в основі відповідних засобів і механізмів в аспектах ідентифікації і аутентифікації. Наводяться конкретні настройки операторів.

В даному розділі будуть розглянуті деякі технічні заходи підвищення захищеності систем. Вибір розглянутих заходів обумовлений можливістю їх реалізації вбудованими засобами операційних систем сімейства Microsoft Windows. Відповідно, рівень захищеності може бути підвищений без додаткових витрат на спеціалізовані засоби захисту.

В теоретичній частині курсу будуть методи, що лежать в основі відповідних засобів і механізмів. У лабораторних роботах розглядаються конкретні настройки операційних систем.

Розглянуті питання можна розділити на дві групи:

• питання, пов'язані з ідентифікацією й аутентифікації користувачів;
• захист переданих повідомлень.

Ідентифікація та аутентифікація

Ідентифікація - присвоєння користувачам ідентифікаторів (унікальних імен або міток) під якими система "знає" користувача. Крім ідентифікації користувачів, може проводитися ідентифікація груп користувачів, ресурсів ІС і т.д. Ідентифікація потрібна і для інших системних задач, наприклад, для ведення журналів подій. У більшості випадків ідентифікація супроводжується аутентификацией. Аутентифікація - встановлення автентичності - перевірка належності користувачеві пред'явленого їм ідентифікатора. Наприклад, на початку сеансу роботи в ІС користувач вводить ім'я і пароль. На підставі цих даних система проводить ідентифікацію (по імені користувача) та аутентифікацію (зіставляючи ім'я користувача і введений пароль).

Система ідентифікації і аутентифікації є одним з ключових елементів інфраструктури захисту від несанкціонованого доступу (НСД) будь-якої інформаційної системи. Відповідно до розглянутої раніше моделлю багаторівневого захисту, аутентифікація користувача комп'ютера відноситься до рівня захисту вузлів.

Зазвичай виділяють 3 групи методів аутентифікації.

1. Аутентифікація за наявністю у користувача унікального об'єкта заданого типу. Іноді цей клас методів аутентифікації називають по-англійськи "I have" ( "у мене є"). Як приклад можна привести аутентифікацію за допомогою смарт-карт або електронних USB-ключів.
2. Аутентифікація, заснована на тому, що користувачеві відома деяка конфіденційна інформація - "I know" ( "я знаю"). Наприклад, аутентифікація по паролю. Більш докладно парольні системи розглядаються далі в цьому розділі.
3. Аутентифікація користувача за його власним унікальним характеристикам - "I am" ( "я є"). Ці методи також називаються біометричними.

Нерідко використовуються комбіновані схеми аутентифікації, які об'єднують методи різних класів. Наприклад, двофакторна аутентифікація - користувач пред'являє системі смарт-карту і вводить пін-код для її активації.

Найбільш поширеними на даний момент є парольні системи аутентифікації. У користувача є ідентифікатор і пароль, тобто секретна інформація, відома тільки користувачеві (і можливо - системі), яка використовується для проходження аутентифікації.

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

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

Як зазначалося під час розгляду стандарту ISO 17799, рекомендується, щоб користувачі системи підписували документ про збереження конфіденційності пароля. Але порушник також може спробувати підібрати пароль, вгадати його, перехопити і т.д. Розглянемо деякі рекомендації по адмініструванню пральний системи, що дозволяють знизити ймовірність реалізації подібних загроз.

1. Завдання мінімальної довжини використовуються в системі паролів. Це ускладнює атаку шляхом підбору паролів. Як правило, рекомендують встановлювати мінімальну довжину в 6-8 символів.
2. Установка вимоги використовувати в паролі різні групи символів - великі і маленькі букви, цифри, спеціальні символи. Це також ускладнює підбір.
3. Періодична перевірка адміністраторами безпеки якості використовуваних паролів шляхом імітації атак, таких як підбір паролів "за словником" (тобто перевірка на використання в якості пароля слів природної мови і простих комбінацій символів, таких як "тисяча двісті тридцять чотири").
4. Установка максимального і мінімального термінів життя пароля, використання механізму примусової зміни старих паролів.
5. Обмеження числа невдалих спроб введення пароля (блокування облікового запису після заданого числа невдалих спроб увійти в систему).
6. Ведення журналу історії паролів, щоб користувачі, після примусової зміни пароля, не могли знову вибрати собі старий, можливо скомпрометований пароль.

Сучасні операційні системи сімейства Windows дозволяють робити установки, автоматично контролюють виконання вимог 1,2,4-6. При використанні домену Windows, ці вимоги можна поширити на всі комп'ютери, що входять в домен і таким чином підвищити захищеність всій мережі.

Але при впровадженні нових механізмів захисту можуть з'явитися і небажані наслідки. Наприклад, вимоги "складності" паролів можуть поставити в глухий кут недостатньо підготовленого користувача. В даному випадку потрібно пояснити, що з точки зору операційної системи Windows надійний пароль містить 3 з 4 груп символів (великі літери, малі літери, цифри, службові знаки). Аналогічним чином, треба підготувати користувачів і до впровадження блокування облікових записів після кількох невдалих спроб введення пароля. Потрібно пояснити користувачам, що відбувається, а самі правила блокування повинні бути добре продумані. Наприклад, якщо висока ймовірність того, що користувач заблокує свій запис в період відсутності адміністратора, краще ставити блокування не назовсім, а на якийсь термін (30 хвилин, годину і т.д.).

Це призводить до того, що повинна бути розроблена політика управління паролями, які супроводжують її документи, а потім вже проведено впровадження.

При використанні ОС сімейства Windows, виявити облікові записи зі слабкими або відсутніми паролями можна, наприклад, за допомогою утиліти Microsoft Baseline Security Analyzer. Вона ж дозволяє виявити і інші помилки адміністрування. Щоб використовувати ці утиліти, а також налаштування політики паролів присвячена лабораторна робота № 3.

протокол Kerberos

Протокол Kerberos був розроблений в Массачусетському технологічному інституті в середині 1980-х років і зараз є фактичним стандартом системи централізованої аутентифікації і розподілу ключів симетричного шифрування. Підтримується операційними системами сімейства Unix, Windows (починаючи з Windows '2000), тобто реалізації для Mac OS.

У мережах Windows (починаючи з Windows '2000 Serv.) Аутентифікація по протоколу Kerberos v.5 (RFC 1510) реалізована на рівні доменів. Kerberos є основним протоколом аутентифікації в домені, але в цілях забезпечення сумісності c з попередніми версіями, також підтримується протокол NTLM.

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

Протокол Kerberos забезпечує розподіл ключів симетричного шифрування і перевірку автентичності користувачів, що працюють в незахищеній мережі. Реалізація Kerberos - це програмна система, побудована по архітектурі "клієнт-сервер". Клієнтська частина встановлюється на всі комп'ютери мережі, що захищається, крім тих, на які встановлюються компоненти сервера Kerberos. У ролі клієнтів Kerberos можуть, зокрема, виступати і мережеві сервери (файлові сервери, сервери друку і т.д.).

Серверна частина Kerberos називається центром розподілу ключів (англ. Key Distribution Center, скор. KDC) і складається з двох компонент:

• сервер аутентифікації (англ. Authentication Server, скор. AS);
• сервер видачі дозволів (англ. Ticket Granting Server, скор. TGS).

Кожному суб'єкту мережі сервер Kerberos призначає розділяється з ним ключ симетричного шифрування і підтримує базу даних суб'єктів і їх секретних ключів. Схема функціонування протоколу Kerberos представлена ​​на Мал. 5.1 .

Мал.5.1.

протокол Kerberos

Нехай клієнт C збирається почати взаємодію з сервером SS (англ. Service Server - сервер, що надає мережеві сервіси). В дещо спрощеному вигляді, протокол передбачає наступні кроки [ 19 , 20 ]:

1. C-> AS: {c}.

   Клієнт C посилає серверу аутентифікації AS свій ідентифікатор c (ідентифікатор передається відкритим текстом).

2. AS-> C: {{TGT} KAS_TGS, KC_TGS} KC,

   де:

   • KC - основний ключ C;
   • KC_TGS - ключ, що видається C для доступу до сервера видачі дозволів TGS;
   • {TGT} - Ticket Granting Ticket - квиток на доступ до сервера видачі дозволів

   {TGT} = {c, tgs, t1, p1, KC_TGS}, де tgs - ідентифікатор сервера видачі дозволів, t1 - відмітка часу, p1 - період дії квитка.

   запис у цій Угоді означає, що вміст фігурних дужок зашифровано на ключі KX.

   На цьому кроці сервер аутентифікації AS, перевіривши, що клієнт C є в його базі, повертає йому квиток для доступу до сервера видачі дозволів і ключ для взаємодії з сервером видачі дозволів. Вся посилка зашифрована на ключі клієнта C. Таким чином, навіть якщо на першому кроці взаємодії ідентифікатор з послав не клієнт С, а порушник X, то отриману від AS посилку X розшифрувати не зможе.

   Отримати доступ до вмісту квитка TGT не може не тільки порушник, але і клієнт C, тому що квиток зашифрований на ключі, який розподілили між собою сервер аутентифікації і сервер видачі дозволів.

3. C-> TGS: {TGT} KAS_TGS, {Aut1} KC_TGS, {ID}

   де {Aut1} - аутентифікаційний блок - Aut1 = {с, t2}, t2 - мітка часу; ID - ідентифікатор запитуваного сервісу (зокрема, це може бути ідентифікатор сервера SS).

   Клієнт C на цей раз звертається до сервера видачі дозволів ТGS. Він пересилає отриманий від AS квиток, зашифрований на ключі KAS_TGS, і аутентифікаційний блок, що містить ідентифікатор c і мітку часу, яка показує, коли була сформована посилка.Сервер видачі дозволів розшифровує квиток TGT і отримує з нього інформацію про те, кому був виданий квиток, коли і на який термін, ключ шифрування, згенерований сервером AS для взаємодії між клієнтом C і сервером TGS. За допомогою цього ключа розшифровується аутентифікаційний блок. Якщо мітка в блоці збігається з міткою в квитку, це доводить, що посилку згенерував насправді С (адже тільки він знав ключ KC_TGS і міг правильно зашифрувати свій ідентифікатор). Далі робиться перевірка часу дії квитка та часу відправлення посилки 3). Якщо перевірка проходить і діюча в системі політика дозволяє клієнту З звертатися до клієнта SS, тоді виконується крок 4).

4. TGS -> C: {{TGS} KTGS_SS, KC_SS} KC_TGS,

   де KC_SS - ключ для взаємодії C і SS, {TGS} - Ticket Granting Service - квиток для доступу до SS (зверніть увагу, що такий же абревіатурою в описі протоколу позначається і сервер видачі дозволів). {TGS} = {с, ss, t3, p2, KC_SS}.

   Зараз сервер видачі дозволів TGS посилає клієнту C ключ шифрування і квиток, необхідні для доступу до сервера SS. Структура квитка така ж, як на кроці 2): ідентифікатор того, кому видали квиток; ідентифікатор того, для кого видали квиток; відмітка часу; період дії ; ключ шифрування.

5. C-> SS: {TGS} KTGS_SS, {Aut2} KC_SS

   де Aut2 = {c, t4}.

   Клієнт C посилає квиток, отриманий від сервера видачі дозволів, і свій аутентифікаційний блок сервера SS, з яким хоче встановити сеанс захищеного взаємодії. Передбачається, що SS вже зареєструвався в системі і розподілив з сервером TGS ключ шифрування KTGS_SS. Маючи цей ключ, він може розшифрувати квиток, отримати ключ шифрування KC_SS і перевірити справжність відправника повідомлення.

6. SS-> C: {t4 + 1} KC_SS

   Сенс останнього кроку полягає в тому, що тепер уже SS повинен довести C свою справжність. Він може зробити це, показавши, що правильно розшифрував попереднє повідомлення. Ось тому, SS бере позначку часу з аутентификационного блоку C, змінює її заздалегідь певним чином (збільшує на 1), шифрує на ключі KC_SS і повертає C.

Якщо всі кроки виконані правильно і всі перевірки пройшли успішно, то сторони взаємодії C і SS, по-перше, переконалися в справжності один одного, а по-друге, отримали ключ шифрування для захисту сеансу зв'язку - ключ KC_SS.

Потрібно відзначити, що в процесі сеансу роботи клієнт проходить кроки 1) і 2) тільки один раз. Коли потрібно отримати квиток на доступ до іншого сервера (назвемо його SS1), клієнт З звертається до сервера видачі дозволів TGS з уже наявними у нього квитком, тобто протокол виконується починаючи з кроку 3).

При використанні протоколу Kerberos комп'ютерна мережа логічно ділиться на області дії серверів Kerberos. Kerberos-область - це ділянка мережі, користувачі і сервери якого зареєстровані в базі даних одного сервера Kerberos (або в одній базі, що розділяється декількома серверами). Одна область може охоплювати сегмент локальної мережі, всю локальну мережу або об'єднувати кілька пов'язаних локальних мереж. Схема взаємодії між Kerberos-областями представлена ​​на Мал. 5.2 .

Для взаємодії між областями, повинна бути здійснена взаємна реєстрація серверів Kerberos, в процесі якої сервер видачі дозволів однієї області реєструється в якості клієнта в іншій області (тобто заноситься в базу сервера аутентифікації і розділяє з ним ключ).

Після установки взаємних угод, клієнт з області 1 (нехай це буде K11) може встановити сеанс взаємодії з клієнтом з області 2 (наприклад, К21). Для цього K11 повинен отримати у свого сервера видачі дозволів квиток на доступ до Kerberos-сервера, з клієнтом якого він хоче встановити взаємодію (тобто сервера Kerberos KDC2). Отриманий квиток містить позначку про те, в якій області зареєстрований власник квитка. Квиток шифрується на ключі, розділеному між серверами KDC1 і KDC2. При успішну розшифровку квитка, віддалений Kerberos- сервер може бути впевнений, що квиток виданий клієнту Kerberos-області, з якої встановлено довірчі відносини. Далі протокол працює як зазвичай.

Мал.5.2.

Взаємодія між Kerberos-областями

Крім розглянутих, Kerberos надає ще ряд додаткових можливостей. Наприклад, зазначений в структурі квитка параметр p (період часу) задається парою значень "час початку дії" - "час закінчення дії", що дозволяє отримувати квитки відкладеного дії.

Є тип квитка "з правом передачі", що дозволяє, наприклад, серверу виконувати дії від імені який звернувся до нього клієнта.

Два слова про аутентифікації. Якщо Kerberos - протокол розподілу ключів, чи коректно використовувати його для аутентифікації ?! Але як зазначалося вище, якщо все стадії протоколу пройшли успішно, взаємодіючі сторони не тільки розподілили ключ, але і переконалися в справжності один одного, іншими словами - аутентифицироваться один одного.

Що стосується реалізації протоколу Kerberos в Windows, то слід зазначити таке.

1. Ключ користувача генерується на базі його пароля. Таким чином, при використанні слабких паролів ефект від надійного захисту процесу аутентифікації буде зведений до нуля.
2. У ролі Kerberos-серверів виступають контролери домену, на кожному з яких повинна працювати служба Kerberos Key Distribution Center (KDC). Роль сховища інформації про користувачів і паролі бере на себе служба каталогу Active Directory. Ключ, який поділяють між собою сервер аутентифікації і сервер видачі дозволів формується на основі пароля службового облікового запису krbtgt - цей запис автоматично створюється при організації домену і завжди заблокована.
3. Microsoft в своїх ОС використовує розширення Kerberos для застосування криптографії з відкритим ключем. Це дозволяє здійснювати реєстрацію в домені і за допомогою смарт-карт, що зберігають ключову інформацію та цифровий сертифікат користувача.
4. Використання Kerberos вимагає синхронізації внутрішнього годинника комп'ютерів, що входять в домен Windows.

Для збільшення рівня захищеності процесу аутентифікації користувачів, рекомендується відключити використання менш надійного протоколу NTLM і залишити тільки Kerberos (якщо використання NTLM не вимагають застарілі клієнтські ОС).

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