Главная страница
Навигация по странице:

  • Проверяющая сторона Проверяемая сторона СНАР-вызов СНАР-отклик Вычисление хэш-кода Вычисление хэш-кода

  • Протокол S/Key

  • W, =

  • 1 3 .2 .2 . Централизованный контроль удаленного

  • Ресурсные серверы Рис. 13.5. Схема централизованного контроля удаленного доступа

  • Информация. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. В. Ф. Шаньгининформационная безопасность компьютерных систем


    Скачать 5.69 Mb.
    НазваниеВ. Ф. Шаньгининформационная безопасность компьютерных систем
    АнкорИнформация
    Дата18.12.2022
    Размер5.69 Mb.
    Формат файлаpdf
    Имя файлаИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ.pdf
    ТипДокументы
    #850081
    страница17 из 23
    1   ...   13   14   15   16   17   18   19   20   ...   23
    Протокол СНЛР
    В протоколе CHAP используется секретный статический па­
    роль. В отличие от протокола РАР, в протоколе CHAP пароль каждого пользователя для передачи по линии связи шифруется на основе случайного числа полученного от сервера. Такая тех­
    нология обеспечивает не только защиту пароля от хищения, но и защиту от повторного использования злоумышленником пере­
    хваченных пакетов с зашифрованным паролем. Протокол CHAP применяется в современных сетях гораздо чаще, чем РАР, так как он использует передачу пароля по сети в защищенной фор­
    ме, и, следовательно, гораздо безопаснее [9].
    Шифрование пароля в соответствии с протоколом CHAP вы­
    полняется с помощью криптографического алгоритма хэширова­
    ния и поэтому является необратимым. В стандарте RFC 1334 для протокола CHAP в качестве хэш-функции определен алгоритм
    MD5, вырабатывающий из входной последовательности любой длины 16-байтовое значение. Хотя минимальной длиной секрета является 1 байт, для повышения криптостойкости рекомендуется
    использовать секрет длиной не менее 16 байт. Спецификация
    CHAP не исключает возможность использования других алго­
    ритмов вычисления хэш-функций.
    Для инициализации процесса аутентификации по протоколу
    CHAP сервер удаленного доступа после установления сеанса связи должен выслать удаленному компьютеру пакет LCP, ука­
    зывающий на необходимость применения протокола CHAP, а также требуемого алгоритма хэширования. Если удаленный ком­
    пьютер поддерживает предложенный алгоритм хэширования, то он должен ответить пакетом LCP о согласии с предложенными параметрами. В противном случае выполняется обмен пакетами
    LCP для согласования алгоритма хэширования.
    После этого начинается аутентификация на основе обмена пакетами протокола CHAP.
    В протоколе CHAP определены пакеты четырех типов:
    • Вызов (Challenge);
    • Отклик (Response);
    • Подтверждение (Success);
    • Отказ (Failure).
    Протокол CHAP использует для аутентификации удаленного пользователя результат шифрования произвольного слова-вызо­
    ва с помощью уникального секрета. Этот секрет имеется как у проверяющей, так и у проверяемой стороны. Процедура аутен­
    тификации начинается с отправки сервером удаленного доступа пакета Вызов (рис. 13.4).
    Проверяющая
    сторона
    Проверяемая
    сторона
    СНАР-вызов
    СНАР-отклик
    Вычисление
    хэш-кода
    Вычисление
    хэш-кода
    СНАР-подтверждение
    или разрыв связи
    Рис. 13.4. Шаги процесса аутентификации по протоколу CHAP
    Удаленный компьютер, получив пакет Вызов, зашифровыва­
    ет его с помощью односторонней функции и известного ему
    секрета, получая в результате дайджест. Дайджест возвращается проверяющей стороне в виде пакета Отклик.
    Так как используется односторонняя хэш-функция, то по перехваченным пакетам Вызов и Отклик вычислить пароль уда­
    ленного пользователя практически невозможно.
    Получив пакет Отклик, сервер удаленного доступа сравнива­
    ет содержимое результата из полученного пакета Отклик с ре­
    зультатом, вычисленным самостоятельно. Если эти результаты совпадают, то аутентификация считается успешной и сервер вы­
    сылает удаленному компьютеру пакет Подтверждение.
    В противном случае сервер удаленного доступа высылает па­
    кет Отказ и разрывает сеанс связи.
    Пакет Вызов должен быть отправлен сервером повторно, если в ответ на него не был получен пакет Отклик. Кроме того, пакет Вызов может отправляться периодически в течение сеанса удаленной связи для проведения динамической аутентификации, чтобы убедиться, что противоположная сторона не была подме­
    нена. Соответственно пакет Отклик должен отправляться прове­
    ряемой стороной в ответ на каждый принятый пакет Вызов.
    Протокол S/Key
    Одним из наиболее распространенных протоколов аутенти­
    фикации на основе одноразовых паролей является стандартизо­
    ванный в Интернете протокол S/Key (RFC 1760) [9, 32]. Этот протокол реализован во многих системах, требующих проверки подлинности удаленных пользователей, в частности в системе
    TACACS+ компании Cisco.
    Перехват одноразового пароля, передаваемого по сети в про­
    цессе аутентификации, не предоставляет злоумышленнику воз­
    можности повторно использовать этот пароль, так как при следую­
    щей проверке подлинности необходимо предъявлять уже другой пароль. Поэтому схема аутентификации на основе одноразовых паролей, в частности S/Key, позволяет передавать по сети однора­
    зовый пароль в открытом виде и, таким образом, компенсирует ос­
    новной недостаток протокола аутентификации РАР.
    Однако следует отметить, что протокол S/Key не исключает необходимость задания секретного пароля для каждого пользо­
    вателя. Этот секретный пароль используется только для генера­
    ции одноразовых паролей. Для того чтобы злоумышленник не смог по перехваченному одноразовому паролю вычислить сек­
    ретный исходный пароль, генерация одноразовых паролей вы­
    полняется с помощью односторонней, т. е. необратимой, функ­
    ции. В качестве такой односторонней функции в спецификации протокола S/Key определен алгоритм хэширования MD4 (Mes­
    sage Digest Algorithm 4). Некоторые реализации протокола S/Key в качестве односторонней функции используют алгоритм хэши­
    рования MD5 (Message Digest Algorithm 5).
    Поясним основную идею протокола S/Key на следующем примере.
    Пусть удаленному пользователю (проверяемой стороне) для регулярного прохождения аутентификации необходим набор из
    100 одноразовых паролей.
    Проверяемой стороне заранее назначается генерируемый случайный ключ К в качестве ее секретного постоянного пароля.
    Затем проверяющая сторона выполняет процедуру инициализа­
    ции списка одноразовых N= 100 паролей. В ходе данной проце­
    дуры проверяющая сторона с помощью односторонней функции
    h вычисляет по ключу К проверочное значение ѵѵ10| для 1-го од­
    норазового пароля. Для вычисления значения ѵѵ101 ключ К под­
    ставляют в качестве аргумента функции И и данная функция ре­
    курсивно выполняется 101 раз:
    W, = h ( K) , w
    2
    = h(h(K)), w
    3
    = h(h(h(K))), wioi = h(h(h(...h(K)...))) = hm (K).
    Идентификатор пользователя и соответствующий этому поль­
    зователю секретный ключ К, а также несекретные числа N и ѵѵ101 сохраняются в БД проверяющей стороны. Число N является но­
    мером одноразового пароля для очередной аутентификации из списка одноразовых паролей. Следует отметить, что после ис­
    пользования каждого такого одноразового пароля номер N умень­
    шается на единицу.
    В процессе очередной аутентификации, проводимой после инициализации, проверяемая сторона предоставляет проверяю­
    щей стороне свой идентификатор, а та возвращает соответствую­
    щее этому идентификатору число N. В нашем примере N= 100.
    Затем проверяемая сторона вычисляет по своему секретному ключу К одноразовый пароль
    w[0Q= hm( - - MK) ) - - . ) ) ) = hm(K)
    и посылает его проверяющей стороне.

    Получив значение ѵѵ{00, проверяющая сторона выполняет над ним 1 раз одностороннюю функцию w{01 = h(w'm ). Далее проверяющая сторона сравнивает полученное значение w,'0I со значением w101 из БД. Если они совпадают, то это означает, что и wJoo = ѵѵ100 и, следовательно, аутентификация является ус­
    пешной.
    В случае успешной аутентификации проверяющая сторона заменяет в БД для проверяемой стороны число w101 на получен­
    ное от нее число ѵѵ^, а число N на N= N - 1. С учетом того, что при успешной аутентификации номер одноразового пароля
    N
    для
    очередной аутентификации уменьшился на 1, в БД про­
    веряющей стороны совместно с идентификатором и секретным ключом К проверяемой стороны будут храниться числа ( N - 1) и wI00. Здесь под ѵѵ100 понимается полученный от проверяемой стороны при успешной аутентификации последний одноразо­
    вый пароль. После использования очередного списка одноразо­
    вых паролей процедура инициализации должна выполняться снова.
    Иногда желательно, чтобы пользователь имел возможность сам назначать секретный постоянный пароль. Для осуществле­
    ния такой возможности спецификация S/Key предусматривает режим вычисления одноразовых паролей не только на основе секретного пароля, но и на основе генерируемого проверяющей стороной случайного числа. Таким образом, в соответствии с протоколом S/Key за каждым пользователем закрепляется иден­
    тификатор и секретный постоянный пароль.
    Перед тем как проходить аутентификацию, каждый пользо­
    ватель должен сначала пройти процедуру инициализации оче­
    редного списка одноразовых паролей, т. е. фазу парольной ини­
    циализации. Данная фаза выполняется по запросу пользователя на сервере удаленного доступа.
    Для ускорения процедуры аутентификации определенное число одноразовых паролей, например несколько десятков, мо­
    жет быть вычислено заранее и храниться на удаленном компью­
    тере в зашифрованном виде.
    Протокол аутентификации на основе одноразовых паролей
    S/Key применяют, в частности, для улучшения характеристик протоколов централизованного контроля доступа к сети удален­
    ных пользователей TACACS и RADIUS.

    1 3 .2 .2 . Централизованный контроль удаленного
    доступа
    Для управления удаленными соединениями небольшой ло­
    кальной сети вполне достаточно одного сервера удаленного дос­
    тупа. Однако если локальная сеть объединяет относительно боль­
    шие сегменты и число удаленных пользователей существенно возрастает, то одного сервера удаленного доступа недостаточно.
    При использовании в одной локальной сети нескольких сер­
    веров удаленного доступа требуется централизованный контроль доступа к компьютерным ресурсам.
    Рассмотрим, как решается задача контроля доступа к сети удаленных пользователей в соответствии с обычной схемой, ко­
    гда удаленные пользователи пытаются получить доступ к сете­
    вым ресурсам, которые находятся под управлением нескольких разных ОС. Пользователь дозванивается до своего сервера уда­
    ленного доступа, и RAS выполняет для него процедуру аутенти­
    фикации, например по протоколу CHAP. Пользователь логиче­
    ски входит в сеть и обращается к нужному серверу, где снова проходит аутентификацию и авторизацию, в результате чего по­
    лучает или не получает разрешение на выполнение запрошенной операции.
    Нетрудно заметить, что такая схема неудобна пользователю, поскольку ему приходится несколько раз выполнять аутентифи­
    кацию — при входе в сеть на сервере удаленного доступа, а по­
    том еще каждый раз при обращении к каждому ресурсному сер­
    веру сети. Пользователь вынужден запоминать несколько разных паролей. Кроме того, он должен знать порядок прохождения разных процедур аутентификации в разных ОС. Возникают так­
    же трудности с администрированием такой сети. Администратор должен заводить учетную информацию о каждом пользователе на каждом сервере. Эти разрозненные БД трудно поддерживать в корректном состоянии. При увольнении сотрудника сложно ис­
    ключить его из всех списков. Возникают проблемы при назначе­
    нии паролей, существенно затрудняется аудит.
    Отмеченные трудности преодолеваются при установке в сети централизованной службы аутентификации и авторизации. Для централизованного контроля доступа выделяется отдельный сер­
    вер, называемый сервером аутентификации. Этот сервер служит для проверки подлинности удаленных пользователей, определе-
    2 0
    *
    ния их полномочий, а также фиксации и накопления регистра­
    ционной информации, связанной с удаленным доступом. На­
    дежность защиты повышается, если сервер удаленного доступа запрашивает необходимую для аутентификации информацию непосредственно у сервера, на котором хранится общая БД сис­
    темы зашиты компьютерной сети.
    Однако в большинстве случаев серверы удаленного доступа нуждаются в посреднике для взаимодействия с центральной БД системы защиты, например со службой каталогов.
    Большинство сетевых ОС и служб каталогов сохраняют эта­
    лонные пароли пользователей с использованием одностороннего хэширования, что не позволяет серверам удаленного доступа, стандартно реализующим протоколы РАР и CHAP, извлечь от­
    крытый эталонный пароль для проверки ответа.
    Роль посредника во взаимодействии между серверами уда­
    ленного доступа и центральной БД системы защиты может быть возложена на сервер аутентификации. Централизованный кон­
    троль удаленного доступа к компьютерным ресурсам с помощью сервера аутентификации выполняется на основе специализиро­
    ванных протоколов. Эти протоколы позволяют объединять ис­
    пользуемые серверы удаленного доступа и сервер аутентифика­
    ции в одну подсистему, выполняющую все функции контроля удаленных соединений на основе взаимодействия с центральной
    БД системы защиты. Сервер аутентификации создает единую точку наблюдения и проверки всех удаленных пользователей и контролирует доступ к компьютерным ресурсам в соответствии с установленными правилами.
    К наиболее популярным протоколам централизованного контроля доступа к сети удаленных пользователей относятся протоколы TACACS (Terminal Access Controller Access Control
    System) и RADIUS (Remote Authentication Dial-In User Service).
    Они предназначены в первую очередь для организаций, в цен­
    тральной сети которых используется несколько серверов удален­
    ного доступа. В этих системах администратор может управлять
    БД идентификаторов и паролей пользователей, предоставлять им привилегии доступа и вести учет обращений к системным ре­
    сурсам [9].
    Протоколы TACACS и RADIUS требуют применения отдель­
    ного сервера аутентификации, который для проверки подлинно­
    сти пользователей и определения их полномочий может исполь­
    зовать не только собственную БД, но и взаимодействовать с со­
    временными службами каталогов, например с NDS (Novell
    Directory Services) и Microsoft Windows NT Directory Service. Сер­
    веры TACACS и RADIUS выступают в качестве посредников ме­
    жду серверами удаленного доступа, принимающими звонки от пользователей, с одной стороны, и сетевыми ресурсными серве­
    рами — с другой. Реализации TACACS и RADIUS могут также служить посредниками для внешних систем аутентификации.
    Рассмотрим особенности централизованного контроля уда­
    ленного доступа на примере протокола TACACS (рис. 13.5).
    Система TACACS выполнена в архитектуре клиент—сервер
    [32]. В компьютерной сети, включающей несколько серверов удаленного доступа, устанавливается один сервер аутентифика­
    ции, который называют сервером TACACS (обычно это програм­
    ма, работающая в среде универсальной ОС, чаще всего Unix).
    На сервере TACACS формируется центральная база учетной информации об удаленных пользователях, включающая их име­
    на, пароли и полномочия. В полномочиях каждого пользователя задаются подсети, компьютеры и сервисы, с которыми он может
    Ресурсные серверы
    Рис. 13.5. Схема централизованного контроля удаленного доступа
    работать, а также различные виды ограничений, например вре­
    менные ограничения. На этом сервере ведется БД аудита, в ко­
    торой накапливается регистрационная информация о каждом логическом входе, продолжительности сессии, а также времени использования ресурсов сети.
    Клиентами сервера TACACS являются серверы удаленного доступа, принимающие запросы на доступ к ресурсам сети от удаленных пользователей. В каждый такой сервер встроено ПО, реализующее стандартный протокол, по которому они взаимо­
    действуют с сервером TACACS. Этот протокол также называется
    TACACS.
    Протокол TACACS стандартизует схему взаимодействия сер­
    веров удаленного доступа с сервером TACACS на основе задания возможных типов запросов, ответов и соединений. Определены запросы, с которыми клиенты могут обращаться к серверу
    TACACS. Сервер на каждый запрос должен ответить соответст­
    вующим сообщением. Протокол задает несколько типов соедине­
    ний, каждое из которых определяется как последовательность пар запрос—ответ, ориентированная на решение отдельной задачи.
    Определено три типа соединений:
    • AUTH — выполняется только аутентификация;
    • LOGIN — выполняется аутентификация и фиксируется ло­
    гическое соединение с пользователем;
    • SLIP — выполняется аутентификация, фиксируется логи­
    ческое соединение, подтверждается IP-адрес клиента.
    С помощью соединения AUTH серверы удаленного доступа перенаправляют серверу TACACS поток запросов на логическое подключение пользователей к сети в целом. Соединение LOGIN служит для перенаправления запросов серверу TACACS на логи­
    ческое подключение пользователей к отдельным компьютерам локальной сети.
    При соединении AUTH сервер удаленного доступа посылает на сервер TACACS только одно сообщение — пакет AUTH, на который сервер TACACS отвечает сообщением REPLY.
    Сервер TACACS на основании имеющихся у него данных проверяет пароль и возвращает ответ в виде пакета REPLY, где сообщает об успехе или неуспехе аутентификации. В соответст­
    вии с протоколом TACACS пароль передается между сервером удаленного доступа и сервером аутентификации в открытом виде.
    Поэтому протокол TACACS необходимо применять совместно с
    протоколом аутентификации по одноразовым паролям, например с протоколом S/Key.
    На основании полученных от сервера TACACS указаний сер­
    вер удаленного доступа выполняет процедуру аутентификации и разрешает или не разрешает удаленному пользователю логически войти в сеть.
    Сервер TACACS может выполнять аутентификацию и авто­
    ризацию удаленных пользователей различными способами:
    • использовать встроенный механизм аутентификации той
    ОС, под управлением которой работает сервер;
    • использовать централизованные справочные системы ОС;
    • использовать системы аутентификации, основанные на од­
    норазовых паролях, например систему SecurlD;
    • передавать запросы другим системам аутентификации, на­
    пример, системе Kerberos.
    Следует отметить, что недостатки протокола TACACS, свя­
    занные с открытой передачей пароля по сети, устранены компа­
    нией Cisco в версии, названной TACACS+. В соответствии с протоколом TACACS+ пароль для передачи по сети шифруется с помощью алгоритма MD5. TACACS+ предусматривает раздель­
    ное хранение БД аутентификационной, авторизационной и учет­
    ной информации, в том числе и на разных серверах. Улучшено взаимодействие с системой Kerberos.
    Другой распространенной системой централизованной аутен­
    тификации при удаленном доступе является система RADIUS.
    По своим функциональным возможностям протоколы TACACS и RADIUS практически эквивалентны и являются открытыми стандартами, однако протокол RADIUS стал более популярен среди производителей систем централизованного контроля уда­
    ленного доступа. Это связано с тем, что основанное на нем сер­
    верное ПО распространяется бесплатно. Кроме того, протокол
    RADIUS менее сложен в реализации.
    1   ...   13   14   15   16   17   18   19   20   ...   23


    написать администратору сайта