Рисунок 3. Аутентификация и авторизация клиента в NIS+.
В настоящее время автономные компьютеры в больших организациях становятся редкостью, что делает актуальным построение эффективной защиты на уровне локальной сети. Более того, надежность информационной системы на системном уровне, как бы высока она ни была, может быть сведена на нет слабостями на сетевом уровне.
Защита информации на сетевом уровне имеет определенную специфику. Если на системном уровне проникнуть в систему можно было лишь в результате раскрытия пользовательского пароля, то в случае распределенной конфигурации становится возможен перехват пользовательских имени и пароля техническими средствами (к примеру, стандартный сетевой сервис telnet пересылает пользовательское имя и пароль в открытом виде). Это заставляет вновь рассматривать задачу аутентификации пользователей, но уже в распределенном случае.
Кроме аутентификации пользователей, в распределенной системе должна производиться также аутентификация машин-клиентов. Высокая степень защиты достигается заменой стандартных открытых сервисов на сервисы, шифрующие параметры пользователя/машины-клиента, чтобы даже перехват пакетов не позволял раскрыть эти данные. Наконец, немаловажное значение имеет аудит событий, происходящих в распределенной информационной среде, поскольку в этих условиях злоумышленник не столь заметен и имеет достаточно времени и ресурсов для выполнения своих задач, если в системе отсутствует автоматическое оповещение и реакция на возможные нарушения.
Стандартные средства защиты, существующие в Solaris 2.x, не являются на данном уровне столь же всеобъемлющими, что и на системном. Дело в том, что если на системном уровне однородность гарантирована и любые изменения могут вводиться достаточно эффективно, то в условиях локальной сети применяется, как правило, набор разнородного оборудования, функционирующего под управлением различных ОС, производители которых априорно не заинтересованы в соответствии средств этих систем концепции безопасности Solaris 2.x.
Защита на сетевом уровне в Solaris 2.x охватывает определенный набор сервисов, достаточно важных и часто используемых, а именно: NIS+ и RPC (NFS). Дополняет указанные меры поддержка в Solaris 2.x клиентской части сервера аутентификации Kerberos, что защищает такие "открытые" сервисы, как telnet и rlogin/rsh.
Сетевой информационный сервис (NIS) служит для централизованного управления информационными ресурсами в распределенной среде. Строящий, подобно DNS-сервису, древовидную структуру имен объектов в сети, NIS+ функционально существенно богаче.
Сервис NIS+ работает на основе набора таблиц, содержащих сведения о машинах, параметрах удаленной загрузки, паролях, ключах аутентификации машин локальной сети, пользователях и группах, подсетях, сетевых масках, адресах Ethernet, сервисах, протоколах, параметрах автоматического монтирования удаленных файловых систем и удаленного вызова процедур (RPC). Поскольку указанная информация является весьма важной с точки зрения безопасности информационной системы, ее надежная защита с учетом всех трех критериев (конфиденциальность, целостность, доступность) абсолютно необходима. Такая защита реализуется при задействовании механизмов авторизации и аутентификации NIS+.
Права доступа в NIS+ определяют, какие операции доступны тому или иному NIS-клиенту. Операции в NIS+ подразделяются на четыре класса: чтение (Read), модификация (Мodify), создание (Create), удаление (Destroy). Каждое взаимодействие между клиентом и сервером может сводиться к запросу на проведение действий какого-либо из этих классов, и соответственно авторизовываться.
В NIS+ различаются четыре категории сетевых субъектов: владелец (Owner), группа владельца (Group), все (World), никто (Nobody), причем эти категории не совпадают с упоминавшимися выше категориями пользователей ОС Solaris и администрируются независимо.
В NIS+ имеется три уровня режима безопасности. Уровень 0 используется для тестирования и установки начального набора имен. В этом режиме любому пользователю NIS+ разрешен доступ к любому из объектов. Уровень 1 также применяется на стадии тестирования и отладки. В этом режиме используется тип аутентификации LOCAL, когда параметром служит идентификатор пользователя. В случае, если он не будет найден, клиенту предоставляются права Nobody. При этом все механизмы авторизации работают в полной мере. Наконец, на уровне 2 производится аутентификация клиентов NIS+ с использованием DES-ключей, которая и будет рассмотрена далее.
NIS+ разделяет клиентов, в зависимости от требуемого сервиса, на две категории: клиент-пользователь и клиент-машина. Клиент выступает как клиент-машина, если запрашиваемый им сервис предполагает получение полномочий привилегированного пользователя (root). Каждому клиенту соответствует удостоверение (credentials), при помощи которого и производится аутентификация. Удостоверение состоит из сетевого имени ( unix.UserID@domainname для клиента-пользователя либо unix.HostName@domainname для клиента-машины) и поля верификации, с помощью которого проверяется подлинность и аутентичность удостоверения.
Все удостоверения NIS+ хранятся в одной из таблиц базы данных сетевого информационного сервиса, называемой "Cred table". Для каждого клиента в таблице содержится его имя, тип аутентификации, сетевое имя, открытый (public) и секретный (private) ключи. Удостоверение для каждого из клиентов создается администратором сети (домена сети). Сервер, обслуживающий NIS+, называется мастер-сервером.
Удостоверения клиентов создаются при помощи программы nisaddcred . Эта программа формирует из идентификатора пользователя и имени домена сетевое имя, после чего заносит его в соответствующую таблицу. Для генерации ключей nisaddcred использует сетевой пароль клиента, который может и не совпадать с пользовательским паролем, записанным в файле /etc/shadow . На основании пароля генерируется пара 192-битных ключей в соответствии с алгоритмом Диффи-Хелмана. Ключи также заносятся в NIS+ таблицу.
При посылке запроса на NIS-сервер по умолчанию предполагается, что используется уровень безопасности 2. Если это оказывается не так, последовательно посылаются удостоверения уровней 1 и 0.
Перед генерацией удостоверений уровня 2 (DES-аутентификация) клиент обязан воспользоваться командой keylogin , предоставляющей доступ к его секретному ключу. Команда keylogin берет секретный ключ в таблице NIS+, расшифровывает его с помощью сетевого пароля и помещает в локальную базу данных. Клиент запоминает также открытый ключ сервера, необходимый для посылки последующих запросов.
Рассмотрим процесс аутентификации более подробно. В качестве первого шага клиент по алгоритму Диффи-Хелмана генерирует DES-ключ и порождает временной штамп. Этот штамп кодируется DES-ключом и присоединяется к прочей информации, содержащейся в удостоверении клиента, образуя поле верификации.
При проверке подлинности клиента, сервер по сетевому имени отыскивает в таблице открытый ключ клиента. Затем, используя собственный секретный ключ и открытый ключ клиента, по алгоритму Диффи-Хелмана сервер генерирует DES-ключ, которым расшифровывает временной штамп, переданный в удостоверении. Если разница между временным штампом клиента и текущим временем находится в заданном интервале, аутентификация считается успешной.
Для подтверждения своей подлинности, сервер возвращает клиенту временной штамп, увеличенный на единицу и зашифрованный аналогичным образом.
Рассмотрим теперь процедуру авторизации в NIS+. Как уже упоминалось, существуют четыре категории, в соответствии с принадлежностью к которым в NIS+ назначаются права доступа: владелец, группа владельца, все, никто. К первой категории может быть отнесен клиент, создавший данный объект или получивший его в собственность при помощи процедуры nischown. Как правило, для этой категории возможен любой из видов доступа — либо непосредственно, либо путем изменения соответствующих атрибутов, на что владелец также имеет право.
Один или несколько NIS+ клиентов могут составлять NIS+ группу, на которую распространяются права доступа, присущие категории Group, по аналогии с правами доступа в файловой системе. Информация о NIS+ группах хранится в NIS+ таблице "Объекты".
Любой клиент, прошедший аутентификацию NIS+, получает права категории World. Если же аутентификация не была проведена (не поступило удостоверения клиента), клиент может получить права категории Nobody. Если же удостоверение поступило, но было неправильным, права Nobody на этого клиента не распространяются: ему автоматически запрещается получение сервиса ( Рис. 3 ).
Таблицы NIS+ имеют дополнительный уровень защиты, не предоставляемый для других типов NIS+ объектов. Этот уровень построен на раздельном доступе к строкам и столбцам. Таким образом, для таблицы, в зависимости от требуемого клиентом сервиса, могут проверяться права на доступ к самой таблице, к данной строке и данному столбцу.
Аналогичная идеология аутентификации применяется при реализации другого важного сервиса — сетевой файловой системы (NFS). NFS — исключительно мощный и удобный сервис, однако его использование сопряжено с угрозами безопасности информационной системы. По умолчанию NFS-сервер проводит аутентификацию клиента-машины, а не клиента-пользователя, что дает возможность несанкционированно получить привилегии суперпользователя (root).
Для проведения аутентификации рекомендуется использовать гораздо более безопасный режим защищенных удаленных вызовов процедур, на основе которых строится защищенная сетевая файловая система (Secure NFS).
Как и в случае NIS+, каждый клиент-пользователь и клиент-машина имеют открытый и секретный ключи. При помощи программы keylogin проводится дополнительная аутентификация пользователя, расшифровывается его секретный ключ и передается программе keyserver , участвующей в процедуре RPC. Программа keyserver с секретным ключом пользователя ожидает запроса на RPC-сервис.
С началом транзакции keyserver генерирует случайный сеансовый ключ. Этим ключом шифруется временной штамп машины-клиента. Затем находится открытый ключ сервера и вырабатывается DES-ключ, с помощью которого шифруется ключ сеанса.
Формируется удостоверение клиента, включающее в себя сетевое имя, зашифрованный сеансовый ключ, допустимая разница времени между клиентом и сервером, и шифрованный временной штамп ( Рис. 4 ).
Когда сервер принимает запрос клиента, программа keyserver , установленная на машине-сервере, ищет открытый ключ клиента в своей базе данных и вырабатывает DES-ключ, используемый для расшифровки ключа сеанса. С помощью последнего расшифровывается временной штамп, полученный от клиента, и сравнивается с текущим временем сервера. Аутентификация считается удачной, если разность времени находится в пределах полученного "окна". Удостоверение клиента запоминается сервером, чтобы противостоять попыткам нелегальной аутентификации путем воспроизведения перехваченной информации.
В качестве свидетельства того, что аутентификация успешно проведена и притом "правильным" сервером, клиенту возвращаются его идентификационный номер в таблице сервера и временной штамп, уменьшенный на единицу и шифрованный сеансовым ключом. Последующие запросы клиент формирует, посылая серверу свой идентификационный номер и новые зашифрованные временные штампы. Таким образом, сеансовый ключ передается по сети один раз в шифрованном виде, причем расшифровать его можно, только зная пару соответствующих ключей клиента и сервера.
При использовании механизмов аутентификации, встроенных в Solaris 2.x, необходимо учитывать следующее:
Современные информационные системы, как правило, разнородны как с точки зрения аппаратных средств, так и с точки зрения применяемых операционных систем. Достаточно популярной является комбинация UNIX-серверов с рабочими местами на базе ПК с ОС Windows NT или MS-DOS с соответствующим сетевым расширением. Количество сервисов, требующихся для каждого пользователя, может быть велико, причем некоторые сервисы могут требоваться неявно. Это делает актуальной задачу выделения аутентификации в сетевой конфигурации в особый сервис, с назначением сервера аутентификации.
Стандартом де-факто такого сервера является Kerberos, разработанный в Массачусетском технологическом институте. В настоящее время практически все коммерческие системы аутентификации, как сетевого уровня (CygnusKerberos, OpenVSecure), так и уровня приложений (Tuxedo), реализуют именно этот стандарт.
Система Kerberos представляет собой надежную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. В этом качестве Kerberos-сервер должен быть физически защищен и иметь минимальное количество пользователей (в идеале — только системный администратор с локальной консоли).
Работа в качестве Kerberos-клиента поддерживается в ОС Solaris. В частности, пользователь Solaris может генерировать удостоверение, передаваемое серверу аутентификации, используя команду kinit , и заканчивать сеанс при помощи команды kdestroy . Особенностью системы Solaris 2.x является возможность применить протокол Kerberos для файловых систем NFS. Это позволяет реализовать единый механизм аутентификации для всех видов сетевых сервисов.
Хотя средства Kerberos предоставляют достаточно высокую степень защиты, они не являются абсолютно надежными и имеют ряд отмеченных в литературе слабостей. В настоящее время реализовано несколько расширений Kerberos, использующих те же принципы с некоторыми усложнениями отдельных операций обмена запросами между клиентом и сервером.
Одной из характерных черт современной операционной системы является возможность использования многооконного интерфейса для работы пользователей. Как и большинство UNIX-систем, ОС Solaris использует стандарт X11R5 Массачусетского технологического института. Этот стандарт построен на основе технологии "клиент-сервер", и, соответственно, предполагает предоставление сервиса каждым сервером для любого из клиентов. Поскольку X-сервер управляет такими ресурсами, как экран, клавиатура, "мышь", необходимо проводить разграничение доступа к этим ресурсам. При этом, с одной стороны, пользователь должен иметь возможность вызывать как локальные, так и удаленные X-приложения, в том числе выступая под различными пользовательскими именами, с другой стороны, несанкционированный доступ к этим ресурсам должен быть невозможен.
Для решения сформулированной задачи применяются различные варианты авторизации, поддерживаемые X-сервером. Наиболее простой вариант предполагает авторизацию по имени машины, запрашивающей сервис. Сопоставляя это имя со списком доступа, содержащимся в файле /etc/Xn.hosts и модифицируемым командой host , сервер разрешает или запрещает выполнение запроса клиента.
Поскольку такой механизм авторизации заведомо недостаточен (разрешая работать своим удаленным приложениям, Вы неявно разрешаете работу приложений всех других пользователей этой машины), в X11 применяется механизм авторизации пользователей, называемый MIT-MAGIC-COOKIE. В этом случае, когда происходит инициализация сервера, генерируется последовательность байт, которая записывается в файл .Xauthority пользователя, открывающего сеанс на данном дисплее. После этого любой клиент получит разрешение на работу в данном сеансе только после предоставления этого кода серверу. Права доступа к файлу .Xauthority установлены в виде -rw----, что разрешает его чтение только владельцу.
В Solaris реализован дополнительный механизм авторизации, основанный на защищенных удаленных вызовах процедур с выработкой сеансового ключа (аналогично ситуации с защищенным режимом для NFS). В этом случае в файле .Xauthority содержится список управления доступом с указанием сетевых имен клиентов, которым разрешен доступ во время сеанса данного пользователя, а кроме собственно авторизации добавляется и аутентификация пользователя, что повышает надежность разделения доступа к этим ресурсам системы.
Начиная с версии Solaris 2.5, предоставляется возможность проведения авторизации/ аутентификации X-клиента с использованием сервера аутентификации Kerberos.
|
|
|
| BSM SunSHIELD — инструмент системного аудита | Содержание | Обеспечение доступности данных с помощью Online DiskSuite/Networker |
| Copyright ╘ 1993-2000, Jet Infosystems |
