Аутентификация в сети

Когда пользователь работает с консоли компьютера или с терминала, физически прикрепленного к терминальному порту, модель сессий является вполне приемлемой. При регистрации пользователя создается сессия, ассоциированная с данным терминалом, и далее проблем нет. Аналогично нет никаких проблем при подключении через сеть с коммутацией каналов, например, при "дозвоне" через модем, подключенный к телефонной сети (конечно же, при условии, что мы доверяем связистам). Когда соединение разрывается, сессия считается оконченной.

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

Только контроллеры домена хранят у себя базу данных о пользователях и паролях. При этом основной контроллер хранит основную копию базы, а резервные серверы — ее дубликаты, используемые лишь в тех случаях, когда основной сервер выключен или потерян. Благодаря тому, что все данные собраны в одном месте, можно централизованно управлять доступом ко многим серверам, поэтому домены представляют неоценимые преимущества при организации больших многосерверных сетей.

С точки зрения безопасности доверяемые системы имеют два серьезных недостатка.

Рис. 12.3. Прорыв безопасности в сети с доверяемыми системами

12.4. Имитация доверяемой системы

Первая проблема является практически неизбежной платой за разрешение автоматической регистрации. Наиболее ярко эта проблема была проиллюстрирована упомянутым выше "Червем Морриса" (КомпьютерПресс 1991], который, проникнув в одну из систем, использовал содержимое файлов .rhosts и /etc/hosts.equiv для проникновения в доверяющие системы, полагаясь на то, что межсистемное доверие обычно делают взаимным. Поэтому в средах с высокими требованиями к безопасности часто стремятся ограничить число доверяемых систем, подобно тому, как отсеки кораблей разделяют водонепроницаемыми переборками.

Вторая проблема может быть отчасти решена использованием средств, пре-достаапяемых сетевыми протоколами, например, привязкой всех логических имен доверяемых систем к их сетевым адресам канального уровня. В протоколах TCP/IP это может быть сделано с использованием протокола аrр (Address Resolution Protocol — протокол разрешения адресов), однако надежда на это слаба: многие сетевые карты имеют настраиваемые адреса, а многие реализации сетевых протоколов допускают отправку пакетов с поддельным адресом отправителя.

Более изощренный и намного более надежный метод основан на использовании алгоритма двухключевого шифрования RSA или родственных ему механизмов.