Безопасность

cause you're paranoid don't mean they aren't after you.

Nirvana.

То, что я параноик, еще не означает, что никто не намерен причинить мне вред.

Нирвана.

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

Защита данных практически не имеет смысла без защиты самой системы и прикладного программного обеспечения: если злоумышленник имеет возможность модифицировать код системы или прикладной программы, он может встроить в него ``троянские'' подпрограммы, осуществляющие несанкционированный доступ к данным. Кроме того, следует учитывать возможность проникновения в систему с целью расстроить ее работу - из простого спортивного интереса, с целью диверсии или же чтобы отвлечь внимание администратора от несанкционированного доступа к данным.


*
Часто взлом систем и написание вирусов ради развлечения приравнивают к обычному вандализму. С точки зрения авторов, эти действия все-таки отличаются от битья стекол или отрывания трубок у телефонов-автоматов: вандализм представляет собой акт чистого разрушения, в то время как взлом компьютерной системы требует некоторой интеллектуальной деятельности, которую при желании можно расценить как созидательную. Впрочем, с точки зрения пострадавших разницы между этими действиями практически нет: эмоции пользователя, у которого пропал день работы в результате вирусной активности, мало отличаются от эмоций человека, который не может вовремя позвонить по телефону, и сильнее всего в обоих случаях угнетает явная бессмысленность вредоносного действия.
*

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

Особой защитой всегда окружаются код системы и ее конфигурационные данные. Это необходимо не только для того, чтобы защититься от несанкционированного доступа, но и для защиты от повреждения системы ``санкционированным'' пользователем по ошибке.

В популярных публикациях, посвященных теме компьютерной безопасности, часто приходится видеть аналогию с известным соревнованием снаряда и брони: после появления более мощной брони всегда появляются способные ее преодолеть снаряды и так далее до бесконечности. На взгляд авторов, такая аналогия весьма неудачна.

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

Чтобы придать системе практическую ценность, необходимо кому-то и при каких-либо условиях все-таки разрешить доступ. Понятно, что такой отход от идеала делает систему потенциально уязвимой для атак. Понятно также, что все атаки должны быть нацелены на какое-то несовершенство системы защиты - нет и не может быть универсального типа атаки, способного преодолеть любую защиту. Даже расшифровка криптограмм методом ``грубой силы'' - полного перебора - как минимум требует получения доступа к зашифрованным данным, что может оказаться невозможным.

Сказанное справедливо лишь для систем, безопасность которых строится по принципу ``запрещено все, кроме того, что было разрешено явным образом''. По этому принципу строится защита практически всех современных систем общего назначения. В таких системах несанкционированный доступ может происходить лишь из-за несовершенства средств защиты и в каждом случае метод доступа оказывается основан на вполне конкретном несовершенстве.

Если же строить защиту на принципе ``разрешено все, кроме того, что запрещено'' , то аналогия с броней и снарядом оказывается вполне актуальна: разработчик системы безопасности перекрывает лишь пути, до которых дошла его фантазия, все же остальное пространство методов доступа оказывается неперекрыто. Характерным примером может служить эволюция антивирусных средств для DOS и параллельная эволюция технологий разработки вирусов.

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

Идеальная система безопасности должна обеспечивать минимальные трудности для санкционированного доступа к данным и непреодолимые для несанкционированного. Кроме того, она должна обеспечивать легкую и гибкую систему управления санкциями; во многих случаях бывает также полезно отслеживать все попытки несанкционированного доступа.

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

Широко известна известна ошибка в программое fingerd, входившей в систему BSD Unix. Эта программа принимала данные в буфер, выделяемый в локальном стеке, не проверяя, входит ли принимаемая порция данных в буфер. Искусственно вызванное переполнение могло привести к перезаписи стекового кадра процедуры, которое в свою очередь при возврате из подпрограммы могло привести к передаче управления в нежелательное место.

``Червь Морриса'' ([21]) пользовался этой дырой, передавая кусок кода и поддельный стековый кадр, передававший управление на этот код. Код в свою очередь запускал на целевой системе копию командного интерпретатора, исполнявшуюся с привилегиями суперпользователя, Затем червь использовал полученный командный интерпретатор для втягивания в систему своего тела.

Ошибка была обнаружена в 1987 г. и вскоре после обнаружения была исправлена. Практически все современные системы используют безопасную в этом отношении версию fingerd.

Аналогичная ошибка была обнаружена в 1995 году в программе syslogd некоторых коммерческих версий Unix.

В обоих случаях ошибка связана с использованием библиотечной функции gets(char * buf), которая принимает ограниченную символом '\n' строку данных из стандартного потока ввода, не проверяя буфер на переполнение. В настоящее время функция gets поддерживается лишь для совместимости и использовать ее не рекомендуется. Вместо нее стандарты ANSI C и POSIX рекомендуют использовать функцию fgets(FILE * stream, size_t bufsize, char * buf);, которая осуществляет проверку на переполнение.

В январе 1996 года была обнаружена проблема, создаваемая одним из антивирусных пакетов для Windows NT. Этот пакет предназначен не для ловли вирусов в самой NT, потому что аналоги вирусов ДОС в защищенных многопользовательских ОС практически нежизнеспособны. Он предназначен для использования на системах, работающих в качестве файлового сервера и хранящих на своих дисках прикладные программы для DOS/MS Windows, используемые станциями локальной сети.

Рабочая часть пакета состоит из процесса-демона (или, по терминологии NT, сервиса (service)), который периодически сканирует исполняемые файлы на дисках с целью поиска в них сигнатур известных вирусов. Сервисный процесс исполняется с привилегиями администратора для того, чтобы установленные пользователями атрибуты защиты от чтения или записи не мешали сканированию или ``лечению'' зараженных файлов.

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

Администратор любой многопользовательской системы обязан следить за появляющимися сообщениями об обнаруженных ошибках и ``дырах" в системе безопасности и принимать меры для устранения и компенсации возникающих проблем.

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

Например, в системах семейства Unix пользователь индентифицируется целочисленным значением uid (user identifier). Пользователь может иметь также символьное имя. Соответствие между символьным и числовым идентификаторами устанавливается на основе содержимого текстового файла /etc/passwd. Каждая строка этого файла описывает одного пользователя и состоит из семнадцати полей, разделенных символом ':'. В первом поле содержится символьное именя пользователя, во втором - числовой идентификатор в десятичной записи. Остальные поля содержат другие сведения о пользователе, например, его полное имя.

Пользовательские программы могут устанавливать соответствие между числовым и символьным идентификаторами самостоятельно, путем просмотра файла /etc/passwd, или использовать библиотечные функции, определенные стандартом POSIX. Во многих реализациях эти функции используют вместо /etc/passwd индексированную базу данных, а сам файл /etc/passwd сохраняется лишь для совместимости со старыми программами.

Нужно отметить, что соответствие между символьным и числовым идентификаторами в Unix не является взаимно однозначным. Одному и тому же числовому идентификатору может соответствовать несколько имен. Кроме того, в Unix можно создать объекты с числовым uid, которому не соответствует никакого символьного имени.

Чаще всего используется принцип сессий работы с машиной. В начале работы пользователь устанавливает соединение и ``входит'' в систему. При ``входе'' происходит его идентификация. Затем пользователь проводит сеанс работы с системой, а по завершении этого сеанса разрегистрируется. Сеанс или сессия жестко связаны с определенным терминалом и/или определенной машиной в сети. При работе в сети есть определенные нюансы, но они будут обсуждаться ниже.

Большинство современных ОС позволяют также запускать задания без входа в систему и создания сессии. Так, системы семейства Unix предоставляют возможность пользователям запускать задачи в заданные моменты астрономического времени или периодически, например, в час ночи в пятницу каждой недели. Каждая такая задача исполняется от имени определенного пользователя - того, кто запросил запуск задачи. Для управления правами доступа в таких ситуациях идентификатор пользователя ассоциируется не с сессией, а с отдельными заданиями, а обычно даже с отдельными задачами.

Так, в системах семейства Unix с каждой задачей (процессом) связано два идентификатора пользователя: реальный и эффективный. В большинстве ситуаций эти идентификаторы совпадают. Таким образом, каждая задача обязательно исполняется от имени определенного пользователя.

Большинство современных ОС общего назначения также связывают с каждой задачей идентификатор пользователя или контекст доступаsecurity context. Исключением в этом отношении является OS/2, в которой такого связывания не происходит. OS/2 позволяет ассоциировать пользовательские идентификаторы и права доступа с файлами, но не с задачами. Идентификаторы хозяина файла используются программами сетевого разделения файлов, например IBM LAN Server, но вся проверка прав доступа и идентификация пользователя происходит внутри задачи-сервера, а не на уровне ОС.

Отсутствие раздельных контекстов доступа у задач не позволяет использовать OS/2 как многопользовательскую систему. Это дает основание многим критикам трактовать название системы как ``ОС пополам'': система, в которой отсутствует половина функций, требуемых от современной ОС общего назначения.

Идентификация пользователя

Петли дверные
Многим скрипят, многим поют:
``Кто вы такие,
Вас здесь не ждут!''

В.Высоцкий.

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

По-английски процесс входа в систему называется login (log in) и происходит от слова log, которое обозначает регистрационный журнал или процесс записи в такой журнал. Наиболее точным переводом слова login является регистрация. Соответственно, процесс выхода называется logout. Его точная русскоязычная калька - разрегистрация - к сожалению, очень неблагозучна

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

Пароль представляет собой последовательность символов. Предполагается, что пользователь запоминает ее и никому не рассказывает. Этот метод хорош тем, что для его использования не нужно никакого дополнительного оборудования - только клавиатура, которая и без того необходима. Но этот метод имеет и ряд недостатков.

Использование паролей основано на следующих трех предположениях:

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

Если вдуматься, первые два требования отчасти противоречат друг другу. Количество легко запоминаемых паролей ограничено, и перебрать все такие пароли оказывается не так уж сложно. Известный в истории сети Internet ``червяк Морриса'' [21]. использовал при подборе паролей следующие варианты:

С первого взгляда видно, что таких ``легко запоминаемых'' вариантов довольно много - никак не меньше нескольких сотен. Набор их вручную занял бы очень много времени, но для компьютера несколько сотен вариантов - это доли секунды. Хотя... Первый слой защиты от подбора пароля заключается именно в том, чтобы увеличить время подбора. Обнаружив неправильный пароль, наученные горьким опытом современные системы делают паузу, прежде чем позволят повторную попытку входа с той же линии. Такая пауза может длиться всего одну секунду, но даже этого достаточно, чтобы превратить процесс подбора пароля из долей секунды в десятки минут.

Второй слой защиты заключается в том, чтобы усложнить пароль и тем самым увеличить количество вариантов. Даже очень простые усложнения сильно увеличивают перебор. Так, простое требование использовать в пароле буквы и верхнего и нижнего регистров увеличивает перебор в -#- раз, где n - это длина пароля. В большинстве современных систем пароль обязан иметь длину хотя бы шесть символов, т.е. количество вариантов увеличивается в 64 раза. Требование использовать в пароле хотя бы один символ, не являющийся буквой, увеличивает число вариантов в -#- раз (в наборе ASCII 43 небуквенных графических символа). Вместо десятков минут подбор пароля, который обязан содержать буквы разных регистров и хотя бы один спецсимвол, займет много дней.

Но если взломщику действительно нужно попасть в систему, он может подождать и несколько дней, поэтому необходим третий слой защиты - ограничение числа попыток. Все современные системы позволяют задать число неудачно набранных паролей, после которого имя блокируется. Это число всегда больше единицы, потому что пользователь - это человек, а людям свойственно ошибаться, но в большинстве случаев такой предел задается не очень большим - обычно 5 - 7 попыток. Однако, этот метод имеет и оборотную сторону - его можно использовать для блокировки пользователей.

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

Наконец, последний слой защиты - это оповещение пользователя (а иногда и администратора системы) о неудачных попытках входа. Если пользователь сам только что нажал не ту кнопку, он при входе увидит, что была одна неудачная попытка, и не будет беспокоиться; однако, если есть сообщения о дополнительных неудачных попытках, время побеспокоиться и разобраться, что же происходит.

Современная техника выбора паролей обеспечивает достаточно высокую для большинства практических целей безопасность. В случаях, где эта безопасность представляется недостаточной - например, если следует всерьез рассматривать опасность принуждения пользователя к раскрытию пароля - можно применять методы идентификации, перечисленные выше, т.е. основанные на механических или электронных ключах или биометрических параметрах. Впрочем, как уже говорилось, такие методы требуют использования специальной аппаратуры.

При использовании паролей возникает отдельная проблема безопасного хранения базы данных со значениями паролей. Как правило, даже администратор системы не может непосредственно получить значения паролей пользователей. Можно привести несколько соображений в пользу такого ограничения.

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

Отцам-основателям Unix этот механизм обеспечения секретности показался настолько надежным, что они даже не стали ограничивать доступ обычных пользователей к базе данных, и выделили для хранения зашифрованных паролей поле в общедоступном для чтения файле /etc/passwd.

Однако ``червь Морриса'' продемонстрировал, что для подбора паролей не нужно перебирать все возможные комбинации символов, поскольку пользователи имеют тенденцию выбирать лишь ограниченное подмножество таких комбинаций. Пользователь, имеющий возможность непосредственно читать закодированные значения паролей, может осуществлять подбор, не обращаясь к системным механизмам аутентикации, то есть делать это очень быстро и практически незаметно для администратора. Этот тип атаки называется словарной атакой (dictionary attack) и весьма опасен для систем, где пользователи неосторожны в выборе паролей.

После осознания опасности словарных атак разработчики систем семейства Unix перенесли значения паролей в недоступный для чтения файл /etc/shadow, где пароли также хранятся в односторонне зашифрованном виде. Это значительно усложняет реализацию словарной атаки, поскольку перед тем, как начать атаку, взломщик должен получить доступ к системе с привилегиями администратора.

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

Идентификация пользователя в сети

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

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

Напротив, в сетях с коммутацией пакетов, к которым относится большинство современных сетевых протоколов (TCP/IP, IPX/SPX, ISO/OSI и т.д.), нет физического понятия соединения. В лучшем случае сетевой протокол предоставляет возможность создавать виртуальные соединения с ``надежной'' связью, в которых гарантируется отсутствие потерь пакетов и сохраняется порядок их поступления. С таким виртуальным соединением вполне можно ассоциировать сессию, как это сделано в протоколах telnet, rlogin/rsh и ftp.

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

Виртуальные сессии вынуждены полагаться на то, что сетевое программное обеспечивает действительно гарантированное соединение, т.е., что никакая ``левая'' машина не может вклиниться в соединение и прослушать его или послать свои поддельные пакеты. Обеспечение безопасности на этом уровне представляет собой отдельную проблему, обсуждение которой увело бы нас далеко от основной темы.

В протоколах, использующих датаграммные соединения, средствами протокола виртуальную сессию создать невозможно. Обычно в этом случае каждый пакет содержит идентификатор пользователя или сессии, от имени которого (в рамках которой) этот пакет послан. Такой подход используется в протоколах работы с файловыми серверами NFS, и NCP (Netware Core Protocol, используемый файловыми серверами Novell Netware). Понятно, что чисто датаграммные протоколы оказываются гораздо более уязвимы для поддельных пакетов и прочих вредоносных воздействий.

Например, NCP, работающий через датаграммный протокол IPX, реализует свой собственный механизм поддержки сессий: все пакеты данной сессии имеют 8-битный номер и пакеты с неправильными номерами просто игнорируются. Одна из программ взлома Netware в течении короткого времени посылала 256 пакетов с различными номерами - хотя бы один пакет оказывался удачным. Для борьбы с такими действиями в Netware 3.12 была введена криптографическая подпись пакетов в пределах сессии.

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

Интересное решение этой задачи предлагается при регистрации на сервере Novell Netware 3.x: при входе пользователя на сервер исполняется специальный командный файл, так называемый login script. Если в нем содержится команда присоединения к другому серверу, программа сначала пробует тот же пароль, который был задан при входе на первый из серверов. Только если этот пароль не подходит, система требует у пользователя ввода пароля. Этот метод обеспечивает одновременную регистрацию на нескольких серверах, но не подходит для динамического создания и разрыва соединений.

Обычно для автоматической регистрации используется модель ``доверяемых'' систем (trusted hosts). Если система B доверяет системе A, то все пользователи, зарегистрированные на системе A, автоматически получают доступ к системе B под теми же именами. Иногда аналогичную возможность можно предоставлять для каждого пользователя отдельно - пользователь сообщает, что при регистрации входа с системы A пароля запрашивать не надо.

Например, протоколы rlogin/rsh, обеспечивающие запуск отдельных команд или командного процессора на удаленной системе, используют файл /etc/hosts.equiv или .rhosts в домашнем каталоге пользователя на удаленной системе. Файл /etc/hosts.equiv содержит имена всех машин, которым наша система полностью доверяет. Файл .rhosts состоит из строк формата.

имя.удаленной.машины          имя_пользователя

При этом имя.удаленной.машины не может быть произвольным, оно обязано содержаться в файле /etc/hosts, в котором собраны имена и адреса всех удаленных машин, ``известных'' системе. То же требование обязательно и для машин, перечисленных в /etc/hosts.equiv.

Например, пользователь fat на машине iceman.cnit.nsu.ru набирает команду rlogin -l fat Indy.cnit.nsu.ru: войти в систему Indy.cnit.nsu.ru под именем fat. Если домашний каталог пользователя fat на целевой машине содержит файл .rhosts, в котором есть строка

iceman.cnit.nsu.ru           fat

то fat получит доступ к системе Indy без набора пароля. Того же эффекта можно добиться для всех одноименных пользователей, если /etc/hosts.equiv содержит строку

iceman.cnit.nsu.ru

Если же fat наберет команду rlogin -l root Indy.cnit.nsu.ru, а в домашнем каталоге пользователя root файла .rhosts нет или он не содержит вышеприведенной строки, команда rlogin потребует ввода пароля, независимо от содержимого файла /etc/hosts.equiv. Нужно отметить, что администраторы обычно вообще не разрешают использовать rlogin для входа под именем root, потому что этот пользователь является администратором системы и обладает очень большими привилегиями.

Модель доверяемых систем обеспечивает большое удобство для пользователей и администраторов и в различных формах предоставляется многими сетевыми ОС. Например, в протоколе разделения файлов SMB (в обиходе этот протокол часто называют NetBIOS, хотя это и не совсем правильно), используемом в Windows for Workgroups, OS/2, Windows NT, Linux и др., испольуется своеобразная модель аутентикации, которую можно рассматривать как специфический случай доверяемых систем.

Аутентикация в SMB основана на понятии домена (domain). Каждый разделяемый ресурс (каталог, принтер и т.д.) принадлежит к определенному домену, хотя и может быть защищен собственным паролем. При доступе к каждому новому ресурсу необходимо подтвердить имя пользователя и пароль, после чего создается сессия, связанная с этим ресурсом. Для создания сессии используется надежное соединение, предоставляемое сетевым протоколом нижнего уровня - именованная труба NetBEUI или соединение TCP. Ввод пароля при каждом доступе неудобен для пользователя, поэтому большинство клиентов - Windows for Workgroups, Windows 95, Windows NT, OS/2 - просто запоминают пароль, введенный при регистрации в домене, и при подключении к ресурсу первым делом пробуют этот пароль. Благодаря этому удается создать у пользователя иллюзию однократной регистрации. Кроме того, если сессия по каким-то причинам оказалась разорвана, например из-за перезагрузки сервера, то можно реализовать прозрачное для пользователя восстановление этой сессии.

С точки зрения клиента нет смысла говорить о межмашинном доверии - клиенту в среде SMB никто не доверяет, и вполне справедливо: обычно это система класса ДОС, не заслуживающая доверия.

Однако серверы обычно передоверяют проверку пароля и идентификацию пользователя выделенной машине, называемой контроллером доменаdomain controller. Домен обязан иметь один основной (primary) контроллер и может иметь несколько резервных (backup). При поступлении запроса на соединение сервер получает у клиента имя пользователя и пароль, но вместо сверки с собственной базой данных он пересылает их контроллеру домена и принимает решение о принятии или отвергании сессии на основании вердикта, вынесенного контроллером.

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

Криптографические методы идентификации

Алгоритм шифрования RSA использует два парных ключа. Сообщение, зашифрованное любым из ключей, может быть расшифровано другим. При этом если нам доступен только один из ключей, мы не можем восстановить другой. Длина ключей составляет несколько десятков или даже сотен байт, поэтому подбор ключей на современной вычислительной технике оказывается сильно затруднен. Обычно более длинный ключ называют ``частным'' (private), а более короткий - общедоступным (public), но для нас это различие не очень существенно. Подробное описание алгоритма RSA можно найти в документе [19].

Способы аутентикации, основанные на RSA, сводятся к следующему механизму:

Для примера рассмотрим принцип RSA-аутентикации в пакете ssh [20] - Secure Shell, разработанной Тату Илоненом (Tatu Ylonen). Пакет представляет собой функциональную замену программ rlogin/rsh и соответствующего этим программам демона rshd. В пакет входят программы ssh (клиент) и sshd (сервер), а также утилиты для генерации ключей RSA и управления ими. ssh использует RSA для прозрачной аутентикации пользователя при входе на удаленную систему. Кроме того, ssh/sshd могут осуществлять шифрование данных, передаваемых по линии во время сеанса связи, и выполнять ряд других полезных функций.

Сервер хранит список известных общедоступных ключей для каждого из пользователей в файле $HOME/.ssh/authorized_keys, где $HOME обозначает домашний каталог пользователя. Файл состоит из строк формата host_name:key - по строке для каждого из разрешенных клиентов. В свою очередь, каждый клиент хранит в файле $HOME/.ssh/private_key свой частный ключ.

Когда с удаленной системы-клиента приходит запрос на аутентикацию, sshd запрашивает общедоступный ключ. Если полученный ключ совпадает с хранящимся в файле значением для этой системы, сервер генерирует случайную последовательность из 256 бит, шифрует ее публичным ключом и посылает клиенту. Клиент расшифровывает посылку своим личным ключом, вычисляет 128-битовую контрольную сумму и возвращают ее серверу. Сервер сравнивает полученную последовательность с правильной контрольной суммой и принимает аутентикацию в случае совпадения. Теоретически контрольные суммы могут совпасть и в случае несовпадения ключей, но вероятность такого события крайне мала.

Методы, основанные на RSA и других алгоритмах шифрования, не могут решить проблемы распространения прорыва безопасности между доверяемыми системами: проникший в доверяемую систему взломщик получает доступ к ``частным'' ключам и может использовать их для немедленной регистрации в любой из доверяющих систем или даже скопировать ключи для проникновения в эти системы в более удобное время. Однако, как уже говорилось выше, это является практически неизбежной платой за разрешение автоматической регистрации в нескольких системах.

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

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


Next: Права доступа Up: Contents

Т.Б.Большаков: tbolsh@inp.nsk.su
Д.В.Иртегов fat@cnit.nsu.ru
latex2html conversion Thu Mar 27 14:44:19 NSK 1997