|
Аутентификация в сети Когда пользователь работает с консоли компьютера
или с терминала, физически прикрепленного к терминальному порту, модель сессий
является вполне приемлемой. При регистрации пользователя создается сессия, ассоциированная
с данным терминалом, и далее проблем нет. Аналогично нет никаких проблем при подключении
через сеть с коммутацией каналов, например, при "дозвоне" через модем,
подключенный к телефонной сети (конечно же, при условии, что мы доверяем связистам).
Когда соединение разрывается, сессия считается оконченной.
В сетях с коммутацией
пакетов, к которым относится большинство современных сетевых протоколов (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. Прорыв безопасности на одной из систем
означает, по существу, прорыв на всех системах, которые доверяют первой (рис.
12.3).
- 2. Возникает дополнительный тип атаки на систему
безопасности: машина, которая выдает себя за доверяемую, но не является таковой
(рис. 12.4).
Рис.
12.3. Прорыв безопасности в сети с доверяемыми системами 
12.4.
Имитация доверяемой системы Первая проблема является практически неизбежной
платой за разрешение автоматической регистрации. Наиболее ярко эта проблема была
проиллюстрирована упомянутым выше "Червем Морриса" (КомпьютерПресс 1991],
который, проникнув в одну из систем, использовал содержимое файлов .rhosts и /etc/hosts.equiv
для проникновения в доверяющие системы, полагаясь на то, что межсистемное доверие
обычно делают взаимным. Поэтому в средах с высокими требованиями к безопасности
часто стремятся ограничить число доверяемых систем, подобно тому, как отсеки кораблей
разделяют водонепроницаемыми переборками.
Вторая проблема может быть отчасти
решена использованием средств, пре-достаапяемых сетевыми протоколами, например,
привязкой всех логических имен доверяемых систем к их сетевым адресам канального
уровня. В протоколах TCP/IP это может быть сделано с использованием протокола
аrр (Address Resolution Protocol — протокол разрешения адресов), однако надежда
на это слаба: многие сетевые карты имеют настраиваемые адреса, а многие реализации
сетевых протоколов допускают отправку пакетов с поддельным адресом отправителя.
Более изощренный и намного более надежный метод основан на использовании алгоритма
двухключевого шифрования RSA или родственных ему механизмов. |
