Аутентифікація в мережі

Коли користувач працює з консолі комп'ютера або з терміналу, фізично прикріпленого до термінального порту, модель сесій є сповна прийнятною. При реєстрації користувача створюється сесія, що асоціюється з даним терміналом, і далі проблем немає. Аналогічно немає жодних проблем при підключенні через мережу з комутацією каналів, наприклад, при "дозвоні" через модем, підключений до телефонної мережі (звичайно ж, за умови, що ми довіряємо зв'язківцям). Коли з'єднання розривається, сесія вважається закінченою.
У мережах з комутацією пакетів, до яких відносяться більшість сучасних мережевих протоколів (TCP/IP, IPX/SPX, ISO/OSI і т. д.), взагалі немає фізичного поняття з'єднання. В кращому разі мережевий протокол надає можливість створювати віртуальні з'єднання з "надійним" зв'язком, в яких гарантується відсутність втрат пакетів і зберігається порядок їх вступу. З таким віртуальним з'єднанням цілком можна асоціювати сесію, як це зроблено в протоколах telnet, rlogin/rsh і ftp.

Протокол telnet
Протокол telnet використовується для емуляції алфавітно-цифрового терміналу через мережу. Користувач встановлює з'єднання і реєструється у видаленій системі так само, як він реєструвався б з фізично підключеного терміналу. Наприклад, в системах сімейства Unix створюється віртуальний пристрій, псевдотермінал (pseudotermina/) /dev/ptyXX, що повністю емулює роботу фізичного терміналу, і система запускає ту ж програму ідентифікації користувача /bin/login, яка використовується для фізичних терміналів. При закінченні сесії з'єднання розривається і псевдотермінальний пристрій звільняється.

Віртуальні сесії вимушені покладатися на те, що мережевий протокол забезпечує дійсно гарантоване з'єднання, тобто що жодна стороння машина не може уклинитися в з'єднання і прослухати його идИ послати свої підроблені пакети. Забезпечення безпеки на цьому рівні або вимагає довіри до мережевої інфраструктури фізичного, канального і мережевого рівнів (лініям зв'язку, комутаторам і маршрутизаторам), або зводиться до використання шифрування і криптографічного підпису пакетів.
У протоколах, що використовують датаграмні з'єднання, засобами протоколу віртуальну сесію створити неможливо. Зазвичай в цьому випадку кожен пакет містить ідентифікатор користувача або сесії, від імені якого (в рамках якої) цей пакет посланий. Такий підхід застосовується в протоколах роботи з файловими серверами NFS і NCP (Netware Core Protocol, використовуваний файловими серверами Novell Netware). Датаграмні протоколи виявляються декілька більш уразливі для підробки пакетів і інших шкідливих дій.

Підпис пакетів в NCP
Наприклад, NCP, що працює через датаграмний протокол IPX, реалізує свій власний механізм підтримки сесій: всі пакети даної сесії мають 8-бітовий номер, і пакети з неправильними номерами просто ігноруються. Одна з техніки злому Netware 3.11 (так звана "Голландська атака") полягає в посилці протягом короткого часу 256 пакетів з різними номерами — хоч би один пакет виявиться вдалим. Для боротьби з такими діями в Netware 3.12 був введений криптографічний підпис пакетів в межах сесії.

Проблема додатково ускладнюється тією обставиною, що в мережі частенько взаємодія відбувається між системами, кожна з яких дозволяє одночасну роботу декількох користувачів. Часто виникає бажання вимагати від користувача реєстрації лише в одній з систем, а доступ в останні системи надавати автоматично.
Зазвичай для автоматичної реєстрації використовується модель систем, що довіряють (trusted hosts). Якщо система В довіряє системі А, те всі користувачі, зареєстровані на системі А, автоматично дістають доступ до системи В під тими ж іменами (мал. 12.2). Інколи аналогічну можливість можна надавати кожному користувачеві окремо — він повідомляє, що при реєстрації входу з системи А пароля запрошувати не треба. Різновидом моделі систем, що довіряють, можна вважати єдину базу облікових записів, що розділяється між машинами.

Мал. 12.2. Системи, що довіряють

Міжмашинна довіра в rlogin/rsh
Протоколи rlogin/rsh, що забезпечують запуск окремих команд або командного процесора на видаленій системі, використовують файл /etc/hosts.equiv або .rhosts у домашньому каталозі користувача на видаленій системі. Файл /etc/hosts.equiv містить імена всіх машин, яким наша система повністю довіряє. Файл .rhosts складається з рядків формату
имя.удаленной.машины ім'я користувача
При цьому имя.удаленной.машины не може бути довільним, воно зобов'язане міститися у файлі /etc/hosts, в якому зібрані імена і адреси всіх видалених машин, "відомих" системі. Та ж вимога обов'язкова і для машин, перерахованих в /etc/hosts.equiv.
Наприклад, користувач fat на машині iceman.cnit.nsu.ru набирає команду
rlogin -I fat Indy.cnit.nsu.ru
— увійти до системи lndy.cnit.nsu.ru під ім'ям fat. Якщо домашній каталог користувача fat на цільовій машині містить файл .rhosts у якому є рядок iceman.cnit.nsu.ru fat то користувач fat дістане доступ до системи Indy без набору пароля. Того ж ефекту можна добитися для всіх однойменних користувачів, якщо /etc/hosts.equiv містить рядок ice man.cnit.nsu.ru
Якщо ж fat набере команду
rlogin -1 root Indy.cnit.nsu.ru,
а в домашньому каталозі користувача root файлу .rhosts немає або він не містить наведеного вище рядка, команда rlogin зажадає введення пароля, незалежно від вмісту файлу /etc/hosts.equiv. Потрібно відзначити, що адміністратори зазвичай взагалі не дозволяють використовувати rlogin для входу під ім'ям root, тому що цей користувач є адміністратором системи і володіє дуже великими привілеями.

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

Аутентифікація SMB
Аутентифікація в SMB заснована на понятті домена (domain). Кожен ресурс (каталог, принтер і т. д.), що розділяється, належить до певного домена, хоча і може бути захищений власним паролем. При доступі до кожного нового ресурсу необхідно підтвердити ім'я користувача і пароль, після чого створюється сесія, пов'язана з цим ресурсом. Для створення сесії використовується надійне з'єднання, що надається транспортним протоколом, — іменована труба NETBEUI або сокет TCP. Введення пароля при кожному доступі незручне для користувача, тому більшість клиентов— просто запам'ятовують пароль, введений при реєстрації в домені, і при підключенні до ресурсу насамперед пробують його. Завдяки цьому удається створити у користувача ілюзію однократної реєстрації. Крім того, якщо сесія по якихось причинах виявилася розірвана, наприклад із-за перезавантаження сервера, то можна реалізувати прозоре для користувача відновлення цієї сесії.
З точки зору клієнта немає сенсу говорити про міжмашинну довіру — клієнтові в середовищі SMB ніхто не довіряє і цілком справедливо: звичайно це система класу ДОС, не заслуговуюча довіри. Проте сервери зазвичай передовіряють перевірку пароля і ідентифікацію користувача виділеній машині, званій контроллером домена (domain controller). Домен зобов'язаний мати один основний (primary) контроллер і може мати декілька резервних (backup), кожен з яких зберігає репліки (періодично синхронизуемые копії) бази облікових записів. Під час вступу запиту на з'єднання сервер отримує у клієнта ім'я користувача і пароль, але замість звірки з власною базою даних він пересилає їх контроллеру домена і приймає рішення про прийняття або відмову в аутентифікації на підставі вердикту, винесеного контроллером.
Лише контроллери домена зберігають у себе базу даних про користувачів і паролі. При цьому основний контроллер зберігає основну копію бази, а резервні сервери — її дублікати, використовувані лише в тих випадках, коли основний сервер вимкнений або втрачений. Завдяки тому, що всі дані зібрані в одному місці, можна централізований управляти доступом до багатьом серверам, тому домени представляють неоцінимі переваги при організації великих багатосерверних мереж.

З точки зору безпеки системи, що довіряють, мають два серйозні недоліки.

1. 1. Прорив безпеки на одній з систем означає, по суті, прорив на всіх системах, які довіряють першою (мал. 12.3).
2. 2. Виникає додатковий тип атаки на систему безпеки: машина, яка видає себе за ту, що довіряє, але не є такий (мал. 12.4).

Мал. 12.3. Прорив безпеки в мережі з системами, що довіряють

12.4. Імітація системи, що довіряє

Перша проблема є практично неминучою платою за дозвіл автоматичній реєстрації. Найяскравіше ця проблема була проілюстрована згаданим вище "Черв'яком Моріса" (Компьютерпресс 1991], який, проникнувши в одну з систем, використовував вміст файлів .rhosts і /etc/hosts.equiv для проникнення в довіряючі системи, покладаючись на те, що міжсистемну довіру зазвичай роблять взаємною. Тому в середовищах з високими вимогами до безпеки часто прагнуть обмежити число систем, що довіряють, подібно до того, як відсіки кораблів розділяють водонепроникними перегородками.
Друга проблема може бути частково вирішена використанням засобів, пре-достаапяемых мережевими протоколами, наприклад, прив'язкою всіх логічних імен систем, що довіряють, до їх мережевих адрес канального рівня. У протоколах TCP/IP це може бути зроблено з використанням протоколу аrр (Address Resolution Protocol — протокол дозволу адрес), проте надія на це слабка: багато мережевих карт мають адреси, що набудовуються, а багато реалізацій мережевих протоколів допускають відправку пакетів з підробленою адресою відправника.
Витонченіший і набагато надійніший метод заснований на використанні алгоритму двохключового шифрування RSA або родинних йому механізмів.