| Аутентификация в сети
Когда пользователь работает с консоли компьютера или с терминала, физически
прикрепленного к терминальному порту, модель сессий является вполне приемлемой.
При регистрации пользователя создается сессия, ассоциированная с данным
терминалом, и далее проблем нет. Аналогично нет никаких проблем при подключении
через сеть с коммутацией каналов, например, при "дозвоне" через
модем, подключенный к телефонной сети (конечно же, при условии, что мы
доверяем связистам). Когда соединение разрывается, сессия считается оконченной.
В сетях с коммутацией пакетов, к которым относится большинство современных
сетевых протоколов (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 или родственных ему механизмов.
|
