Протоколы аутентификации сеанса ррр

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

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

При настройке параметров аутентификации протокола РРР можно выбрать проверку с помощью протоколов РАР или CHAP. Как правило, предпочтение отдается протоколу CHAP. В целом на практике предпочтение обычно отдается протоколу CHAP.

Протокол аутентификации по паролю рар

Протокол РАР предоставляет удаленному узлу простой способ подтвердить свою идентичность путем использования двухэтапного квитирования (handshake). После того как стадия создания РРР-канала закончена, удаленный узел регулярно посылает по ка­налу имя пользователя и его пароль до тех пор, пока идентичность не будет подтверждена или канал не будет закрыт. Пример работы протокола РАР приведен на рис. 13.9.

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

Рис. 13.9. Аутентификация по протоколу РАР

CHAP

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

Рис. 13.10. Аутентификация по протоколу CHAP

После создания канала РРР хост посылает сообщение о вызове на удаленный узел. Удаленный узел посылает в ответ соответствующее значение. Хост сравнивает его с имеющимся у него значением и, если они совпадают, подлинность подтвер­ждается. В противном случае связь прекращается. Пример работы протокола CHAP приведен на рис. 13.10.

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

Инкапсуляция протокола ррр и процесс аутентификации

При конфигурировании аутентификации протокола РРР можно выбрать прото­кол РАР или протокол CHAP. Тип аутентификации определяется с помощью ко­манды encapsulation ppp. Если аутентификации не требуется, то протокол РРР начинает сеанс немедленно. В противном случае процесс переходит на следующую стадию. Процесс аутентификации проиллюстрирован на рис. 13.11.

Рис. 13.11. Процесс аутентификации '

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

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

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

В протоколе CHAP после этапа установки соединения РРР локальный маршрутиза­тор посылает сообщение-вызов удаленному узлу. Удаленный узел отвечает значением, вычисляемом с помощью односторонней хэш-функции (обычно MD5). Локальный маршрутизатор сверяет этот ответ со своим собственным вычисленным хеш-значением. Если эти значения совпадают, то результат аутентификации считается положительным и подтверждается. В противном случае соединение немедленно прерывается.

Приведенные ниже описание этапов и рисунки иллюстрируют последовательность со­бытий, которые происходят в процессе аутентификации по протоколу CHAP между двумя маршрутизаторами. Однако они не соответствуют реальным сообщениям, содержащимся в выводе по команде debug ppp negotiation. Дополнительная информация содержится в документе "Understanding debug ppp negotiation Output", который можно просмотреть по адресу www.cisco.com/warp/public/471/debug_ppp_negotiation.html.

На рис. 13.12 показаны следующие этапы процесса аутентификации.

Этап 1. Вызов поступает на устройство 3640-1. Входной интерфейс сконфигури­рован с помощью команды ррр authentication chap.

Этап 2. Протокол LCP согласовывает опции CHAP и MD5.

Этап 3. При этом вызове требуется вызов CHAP от 3640-1 к вызывающему мар­шрутизатору.

Рис. 13.12. Первый этап процесса аутенти­фикации по протоколу CHAP

На рис 13.13 проиллюстрированы следующие этапы процесса аутентификации CHAP между двумя маршрутизаторами:

Этап 1. Создается пакет протокола CHAP со следующими характеристиками:

01= идентификатор типа пакета вызова

id = порядковый номер вызова

random = случайное число, генерируемое маршрутизатором

3640-1 = аутентификационное имя вызывающей стороны

Этап 2. Значения id и random хранятся на вызываемом маршрутизаторе

Этап 3. Пакет вызова посылается вызывающему маршрутизатору. Поддерживает­ся список ожидающих вызовов.

Рис. 13.13. Второй этап процесса аутентифи­кации протокола CHAP

На рис. 13.14 проиллюстрирован прием пакета вызова от взаимодействующего устройства и его обработка алгоритмом MD5

Рис. 13.14. Третий этап процесса аутентификации протокола CHAP

Маршрутизатор обрабатывает входящий пакет вызова протокола CHAP следую­щим образом.

Этап 1. Значение идентификатора id подается на хеш-генератор алгоритма MD5.

Этап 2. Выбранное случайным образом значение подается на хеш-генератор ал­горитма MD5.

Этап 3. Имя 3640-1 используется для поиска пароля. При этом маршрутизатор ищет позицию, которая соответствует имени пользователя в пакете вызо­ва. В данном примере он ищет следующую информацию: username 3640-1 password pel

Этап 4. Этот пароль подается на хеш-генератор алгоритма MD5.

Результатом является обработанный односторонней хэш-функцией алгоритма MD5 вызов протокола CHAP, который будет отправлен в ответе протокола CHAP.

На рис. 13.15 показан процесс создания ответного пакета протокола CHAP, от­правляемого аутентификатору. На этом рисунке отображены следующие этапы.

Этап 1. Ответный пакет собирается из следующих компонентов:

02 = идентификатор типа ответного пакета протокола CHAP

id = копируется из пакета вызова

hash = выдаваемое хеш-генератором MD5 значение (обработанная хэш-функцией информация пакета вызова)

766-1 = Имя устройства для процесса идентификации. Оно требуется взаимодействующему устройству для поиска имени пользователя и его пароля, которые необходимы для проверки идентичности (она будет более подробно рассмотрена далее).

Этап 2. Пакет ответа посылается инициатору вызова.

Рис. 13.15. 4-й этап процесса аутентификации протокола CHAP

На рис. 13.16 показано, каким образом инициатор вызова обрабатывает пакет от­вета на свой запрос.

Рис. 13.16. 5-й этап процесса аутентификации протокола CHAP

Ответный пакет протокола CHAP обрабатывается (аутентификатором) следую­щим образом.

Этап 1. Идентификатор id используется для нахождения первоначального пакета вызова.

Этап 2. Идентификатор id подается на хеш-генератор алгоритма MD5.

Этап 3. Случайное значение первоначального вызова подается на хеш-генератор алгоритма MD5.

Этап 4. Имя 766-1 используется для поиска пароля в одном из следующих источ­ников:

Локальная база данных, содержащая имена пользователей и их пароли;

Сервер службы удаленной аутентификации удаленного пользователя (Remote Authentication Dial-In User Service — RADIUS) или сервер управляющей системы терминального доступа (Controller Access Con­ trol System — TACACS+)

Этап 5. Пароль подается на хеш-генератор MD5.

Этап 6. Хеш-значение, полученное в ответном пакете, сравнивается с вычислен­ным хеш-значением алгоритма MD5. СНАР-аутентификация считается успешной, если вычисленное и полученное значения равны.

На рис. 13.17 проиллюстрировано сообщение об успешной аутентификации, по­сылаемое вызывающему маршрутизатору.

Рис. 13.17. Шестой этап процесса аутентификации протокола CHAP

Если аутентификация прошла успешно, то пакет протокола CHAP создается из следующих компонентов:

03 = тип сообщения об успешной аутентификации протокола CHAP.

id = Копируется из ответного пакета.

"Welcome in" — просто текстовое сообщение, содержащее понятное пользо­вателю объяснение.

Если результат аутентификации отрицателен, то соответствующий пакет прото­кола CHAP создается из следующих компонентов:

04 = тип сообщения об отрицательном результате аутентификации протокола CHAP;

id = Копируется из ответного пакета;

"Authentication failure" или другое текстовое сообщение, содержащее понятное пользователю объяснение. Пакет успешной аутентификации или отрицательный от­вет направляется вызывающему маршрутизатору.