Существуют различные способы инкапсуляции одного протокола в другой. Рассмотрим протокол GRE (Generic Routing Encapsulation), который позволяет инкапсулировать любой протокол. Это может быть использовано для любых целей.
Будем считать, что имеется пакет, который необходимо инкапсулировать и доставить некоторому получателю. Этот пакет будет являться содержимым GRE-пакета. Получившийся GRE-пакет затем инкапсулируется в пакет некоторого другого протокола, и отправляется. Будем называть этот внешний протокол протоколом доставки.
Результирующий пакет имеет следующий формат:
(рис 5.1) Формат GRE-пакета
В GRE-заголовке содержится тип инкапсулированного протокола. Если содержимым пакета является IPv4, то тип протокола должен быть 0х800.
Когда конечная точка туннеля декапсулирует GRE-пакет, у которого содержимым является пакет IPv4, адрес получателя в заголовке содержи-мого пакета может использоваться для дальнейшей доставки пакета. Долж-на выполняться проверка, что адрес получателя во вложенном пакете не равен адресу в инкапсулирующем пакете, так как это является другим концом туннеля, и в этом случае происходит зацикливание.
В качестве протокола доставки может также использоваться протокол IPv4.
(рис 5.2) Протокол GRE
Virtual Private Network (VPN) – это различные технологии, которые позволяют создавать логические сети, использующие в качестве транспорта другие сетевые протоколы. При этом характеристики безопасности созданной логической сети могут отличаться от характеристик безопасности сети, которая используется в качестве транспорта. Такие сети могут создаваться на разных уровнях стека OSI исходной транспортной сети. Создаваемая логическая сеть не обязательно должна быть маршрутизируемой, она может обеспечивать соединение типа точка-точка.
VPN используются в двух основных сценариях:
При создании VPN всегда следует помнить, что безопасность компьютерной системы и сетевого трафика зависит от многих факторов. Развертывание VPN с использованием той или иной технологии является только частью комплексного подхода к обеспечению безопасности.
Безопасность, обеспечиваемая VPN, зависит от многих параметров операционного окружения, в котором VPN выполняется. Например, от безопасности ОС, источника случайных чисел, способов управления системой и т.д.
Рассмотрим основные протоколы создания VPN и проанализируем их характеристики с точки зрения безопасности создаваемых соединений, возможностей масштабирования и наличия каких-либо дополнительных возможностей.
Таблица 5.1
Терминология
Протокол РРР определяет механизм инкапсуляции для пересылки пакетов, принадлежащих любым сетевым протоколам, по каналам точка-точка 2 уровня. Обычно пользователь получает соединение канального уровня (так называемое L2-соединение) к Network Access Server (NAS), используя одну из технологий доступа типа точка-точка: dial-up POTS, ISDN, ADSL и т.п. Протокол РРР выполняется поверх данного соединения. В простейшем случае завершение L2-соединения и конечная точка РРР-протокола расположены на одном и том же физическом устройстве NAS.
L2TP расширяет возможности РРР, допуская, чтобы конечные точки L2 и РРР были расположены на разных устройствах, соединенных между собой сетью, по которой могут передаваться пакеты. При использовании L2TP пользователь создает L2-соединение с концентратором (например, модемом, ADSL DSLAM и т.п.), затем концентратор туннелирует отдельные РРР-кадры к NAS. Это позволяет обрабатывать РРР-кадры отдельно от точки завершения L2-соединения.
Одно очевидное преимущество такого разделения состоит в том, что вместо требования завершения L2-соединения на NAS (что может требовать тянуть провода на большие расстояния), соединение может заканчиваться на локальном концентраторе, который создает логическую РРР-сессию поверх разделяемой инфраструктуры такой, как frame relay или интернет. С точки зрения пользователя не существует различия между завершением L2 непосредственно на NAS или использованием L2TP.
Протокол L2TP определяет создание туннелей между двумя узлами и последующую инкапсуляцию туннелируемых РРР сессий.
В протоколах, выполняющих пересылку РРР-данных по сети Ethernet, используется следующая терминология.
| L2TP концентратор доступа (L2TP Access Concentrator - LAC) | Узел, который является одной из конечных точек L2TP-туннеля. LAC является противоположной сто-роной L2TP сетевого сервера (LNS). LAC расположен между LNS и удаленной системой и перенаправляет пакеты к каждой из них. Пакеты, посылаемые от LAC к LNS, туннелируются по протоколу L2TP. Соедине-ние между LAC и удаленной системой является либо локальным, либо выполняется по протоколу РРР. Если вместо L2TP используется протокол РРТР, то аналогичный узел называется РРТР концентратор доступа – РАС. |
| L2TP сетевой сервер (L2TP Network Server - LNS) | Узел, который является одной из конечных точек L2TP-туннеля. LNS является противоположной стороной LAC. LNS является логической конечной точкой РРР-сессии, которая туннелируется от удаленной системы с помощью LAC. LNS также является конечной точкой туннеля между LNS и LAC. Если вместо L2TP используется протокол РРТР, то аналогичный узел называется РРТР сетевой сервер – PNS. |
| Сервер сетевого доступа (NAS) | Устройство, предоставляющее пользователям сетевой доступ по требованию. Этот доступ является доступом типа точка-точка, использующим PSTN или ISDN каналы. Функции NAS может выполнять и LAC, и LNS. |
| L2TP/PPTP-туннель | Туннель между LAC и LNS. Туннель состоит из управляющего соединения и нуля или более L2TP-сессий. L2TP/PPTP-туннель передает инкапсулированные дейтограммы PPP и управляющие сообщения между LAC и LNS. |
| L2TP/PPTP-сессия | В протоколах РРТР и L2TP определено понятие сес-сии. LNS и LAC поддерживают состояние для каждого вызова, который инициирован LAC или на который ответил LAC. L2TP-сессия создается между LAC и LNS, когда РРР-соединение установлено между удаленной системой и LNS. Дейтаграммы, относящиеся к РРР-соединению, посылаются по туннелю между LAC и LNS. Между установленными сессиями и соответствующими вызовами существует взаимнооднозначное соответствие. |
| Управляющее соединение L2TP/PPTP | Управляющее соединение используется для установ-ление и поддержки как для сессий, так и самого L2TP/PPTP-туннеля и создается для каждой пары LАС, LNS. Управляющее соединение определяет все характеристики туннеля и связанных с ним сессий. |
Обзор
Протокол РРР предназначен для создания не маршрутизируемых каналов, по которым передаются пакеты между двумя участниками. Каналы являются полнодуплексными и функционируют в обоих направлениях.
Протокол обеспечивает инкапсуляцию различных протоколов сетевого уровня в один канал.
Протокол РРР определяет способ передачи дейтаграмм по последова-тельным каналам. Протокол РРР состоит из следующих протоколов:
Для согласования параметров канала используется протокол управления каналом LCP. Протокол LCP может также выполнять аутентификацию конечных точек канала.
В РРР-каналах необходимо задавать многие параметры маршрутизируемых сетевых протоколов. Например, назначение и управление IP-адресами. Для решения этих проблем используются протоколы управления сетью NCP.
Конфигурирование выполняется с помощью переговоров об используемом наборе опций. Для этого каждая сторона канала описывает противоположной стороне свои возможности и требования.
Для того, чтобы установить соединение точка-точка, каждый конец РРР-канала должен во-первых послать LCP-пакеты для конфигурирования и тестирования канала данных. После того, как канал установлен и выпол-нены переговоры о дополнительных опциях, которые необходимы LCP, РРР должен послать NCP-пакеты для выбора и конфигурирования прото-колов сетевого уровня. После того, как протокол сетевого уровня сконфигурирован, по каналу могут посылаться дейтаграммы.
Канал будет оставаться открытым до тех пор, пока явно не будет закрыт LCP- или NCP-пакетами, или пока не произойдет какое-нибудь внешнее событие.
Диаграмма состояний
В течение своего жизненного цикла РРР-канал проходит через следующие состояния.
(рис 5.3) Диаграмма состояний РРР-канала
Установление канала
Для установления соединения используется LCP-протокол, в котором выполняется обмен конфигурационными пакетами. Инициализация канала выполняется с помощью пакета Configure-Request, на который получатель отвечает Configure-Ack. Инициализация канала завершается, и состояние LCP становится открытым после того, как пакет Configure-Ack отправлен и получен.
Протоколом LCP конфигурируются только те опции, которые не зависят от конкретных протоколов сетевого уровня. Конфигурированием протоколов сетевого уровня занимается отдельные протоколы управления сетью (NCP).
Любые не-LCP-пакеты, полученные в этом состоянии, отбрасываются.
Получатель LCP-запроса на конфигурацию переходит в состояние пересылки дейтаграмм сетевого уровня после инициализации канала и выполнения аутентификации.
(рис 5.4) Пример LCP-запроса
(рис 5.5) Пример запроса на аутентификацию
Аутентификация
В некоторых случаях перед обменом пакетами протокола сетевого уровня может требоваться аутентификация противоположной стороны.
Аутентификация должна иметь место сразу же после установления канала.
Переход из состояния аутентификации в состояние пересылки дейтаграмм сетевого уровня не происходит до тех пор, пока аутентификация не завершиться.
(рис 5.6) СНАР- аутентификация в протоколе РРР
Протокол СНАР используется для периодической проверки аутентификации противоположной стороны с помощью трех шагового рукопожатия. Протокол выполняется при начальном установлении канала и может повторяться в любое время после того, как канал установлен.
Преимущества
СНАР обеспечивает защиту от replay-атак, если в качестве запроса по-сылается случайное значение.
Данный метод аутентификации основан на том, что оба участника знают некий секрет, который никогда не посылается по каналу.
Хотя аутентифицируется только одна сторона, СНАР-переговоры можно вести в обоих направлениях с тем же самым секретом, обеспечивая взаимную аутентификацию.
Так как данный протокол может использоваться для аутентификации многими различными системами, поле name может использоваться для нахождения нужного секрета. С помощью данного поля можно также поддерживать несколько пар name/secret для каждой системы.
Недостатки
Требуется, чтобы секрет был доступен в незашифрованном виде. Секрет, хранящейся в базе данных в виде результата применения односторонней функции, не может использоваться.
Это неудобно при большом количестве участников, так как каждый секрет должен храниться на обоих концах канала.
Чтобы избежать посылки секрета по другим каналам в сети, рекомендуется, чтобы значения запроса и ответа проверялись на центральном сервере, а не каждым сервером сетевого доступа. В противном случае секрет должен будет посылаться этим серверам в зашифрованном виде. Также требуется определенная форма доверия участников друг другу.
Требования разработки
Предпочтительнее, чтобы секрет был примерно той же длины, что и значение хэша используемой хэш-функции. Например, 16 октетов для MD5. Используемая хэш-функция должна гарантировать, что вычислительно сложно определить секрет, зная запрос и ответ.
Каждый запрос является уникальным, так как повторное использование предыдущего значения запроса позволит атакующему ранее перехваченный ответ.
Формат конфигурационного параметра
Формат конфигурационного параметра протокола Аутентификации следующий:
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Algorithm | +-+-+-+-+-+-+-++-+ Type 3 Length 5 Authentication Protocol c223 Algorithm
определяет используемый алгоритм. Значения алгоритмов определяются IANA. Для MD5 значением является 5.
Формат пакета
В информационное поле РРР-кадра инкапсулируется ровно один СНАР-пакет.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Code | Identifier | Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Data ... +-+-+-+-+
Code определяет тип СНАР-пакета.
1 Запрос
2 Ответ
3 Успех
4 Неуспех
Identifier используется для определения пар соответствующих запросов и ответов.
Length определяет длину СНАР-пакета.
Data формат данного поля определяется полем Code.
Пакет Challenge используется в качестве первого пакета протокола СНАР. Аутентифицирующая сторона посылает СНАР-пакет с полем Code, установленным в 1 (Challenge). Могут посылаться дополнительные пакеты Challenge до тех пор, пока не будет получен пакет Response или не истечет счетчик повторов.
Пакет Challenge также может передаваться в любое время в течение выполнения протокола сетевого уровня, чтобы гарантировать, что не было подмены участников соединения.
Противоположная сторона ожидает пакеты Challenge в течение фаз аутентификации и протокола сетевого уровня. После получения пакета Challenge участник посылает СНАР-пакет и полем Code, установленным в 2 (Response).
После того, как пакет Response получен, аутентифицирующая сторона сравнивает значение, полученное в ответе, с собственным вычисленным значением. В зависимости от результата аутентифицирующая сторона посылает либо пакет Success, либо пакет Failure.
Следует понимать, что, так как пакет Success может быть потерян, аутентифицирующая сторона повторяет пакеты Response в течение вы-олнения протокола сетевого уровня после завершения фазы аутентификации. Все пакеты Response, полученные в любой другой фазе, отбрасываются без отправления ответа.
Если пакет Failure потерян, аутентифицирующая сторона завершает соединение, и пакеты Terminate-Request и Terminate-Ack протокола сетевого уровня обеспечивают альтернативный способ определения, что аутентификация была неудачной.
Поле Identifier изменяется в каждом новом пакете Challenge. Поле Identifier в пакете Response копируется из поля Identifier соответствующего пакета Challenge.
В поле Data содержатся значения Value и Name. Значение Value в пакете Challenge должно быть уникальным и не зависеть от секрета. Значение Value в пакете Response является результатом вычисления хэш-функции от следующих значений: Identifier, secret, значение Value из пакета Challenge.
В поле Name записана идентификация системы, которая послала пакет. В этом случае синтаксис может быть любой, как строка символов ASCII, так и уникальный идентификатор в ASN.1 синтаксисе.
Обсуждение безопасности
Не существует особых требований, как и когда должна выполняться повторная попытка при неудачной аутентификации. Тем не менее, в протоколе сетевого уровня может в любой момент начаться протокол аутентификации. Считается, что счетчик неудачных попыток аутентификации не должен сбрасываться до тех пор, пока не будет выполнена успешная аутентификация или не сброшено соединение.
Не существует требования, чтобы аутентификация была взаимной или что в обоих направлениях должен выполняться один и тот же протокол.
Расширения Microsoft РРР СНАР версии 1
Обзор
Microsoft разработал протокол MS-CHAP для аутентификации удаленных рабочих станций, который с одной стороны имел бы привычную для локальных пользователей функциональность, а с другой стороны использовал бы алгоритмы шифрования и хэширования.
MS-CHAP основан на протоколе СНАР. Различия между этими протоколами следующие:
Конфигурирование LCP
Конфигурирование LCP для MS-CHAP аналогично конфигурированию стандартного СНАР, за исключением того, что поле Algorithm имеет значение 0x80, а не 0x05. Реализации РРР, который не поддерживают MS-CHAP, но корректно реализуют LCP Config-Rej, не должны иметь проблем с данным нестандартным параметром.
Пакет Challenge
Пакет Challenge в протоколе MS-CHAP аналогичен пакету Challenge в стандартном протоколе СНАР.
Аутентифицирующая сторона посылает 8-октетное значение в поле Value.
Пакет Response
Формат пакета Response аналогичен формату пакета Response в стандартном протоколе СНАР. Однако поле Value отличается:
Совместимый с LAN Manager ответ является результатом выполнения функции LmChallengeResponse()от пароля и полученного запроса. Пароль LAN Manager не может быть длиннее 14 символов и чувствителен к регистру.
Совместимый с Window NT ответ является результатом выполнения функции NTChallengeResponse()от пароля и полученного запроса. Пароль Windows NT является строкой от 0 до 256 символов Unicode, пароль чувствителен к регистру. Обычно длина пароля в Windows NT ограничена 14 символами.
Если установлен флаг "Используется совместимость ответа с Windows NT", то используется Windows NT ответ. Ответ "LAN Manager" может ис-пользоваться, если аккаунт не имеет хэша пароля Windows NT, например, еасли пароль не был изменен после загрузки из базы данных аккаунтов LAN Manager 2.x. Если флаг установлен, то ответ Windows NT игнорирует-ся и используется ответ LAN Manager.
Поле Name содержит имя пользовательского аккаунта противоположной стороны. Имя домена Windows NT может являться префиксом имени пользователя.
Пакет Success
Формат пакета Success аналогичен формату стандартного пакета Success в СНАР.
Пакет Failure
Формат пакеты Failure аналогичен формату стандартного пакета Failure в протоколе СНАР. Однако, в отличии от стандартных правил СНАР, содержимое поля Message влияет на протокол. Формат поля Message следующий:
E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv
Где "eeeeeeeeee" есть десятичный код ошибки, который может быть одним из следующих значений:
646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD
Если установлен флаг "r", то возможна повторная попытка, если флаг не установлен, то повторная попытка не допускается. Если аутентифицирующая сторона устанавливает данный флаг в 1, она отключает короткие таймауты, предполагая, что противоположная сторона предложит пользователю ввести новые креденциалы и повторить ответ.
"cccccccccccccccc" является новым значением вызова (challenge). Данное поле не является обязательным. Если оно не посылается, то аутентифицирующая сторона считает, что повторный ответ будет вычислен с использованием предыдущего значения вызова, к которому прибавлено десятичное число 23.
10 цифр "vvvvvvvvvv" содержат код версии, обозначающий версию протокола MS-CHAP, поддерживаемую сервером. Это важно только при выборе пакета Change Password. Если поле отсутствует, то считается, что используется версия 1.
Пакет Change Password
Пакет Change Password не посылается в стандартном протоколе СНАР. Допускается, чтобы противоположная сторона изменила пароль аккаунта, указанного в последнем пакете Response. В версии 1 пакет Change Password должен посылаться только в том случае, если аутенти-фицирующая сторона возвратила ERROR_PASSWD_EXPIRED.
Обсуждение безопасности
Аутентифицирующая сторона должна ограничить число попыток ввода пароля, чтобы предотвратить атаки, связанные с перебором паролей. Так как пароль скрывается с помощью хэш-функции, то возможность взлома пароля зависит от криптографической стойкости используемой хэш-функции. Также необходимо достаточно часто менять пароль.
Расширения Microsoft PPP CHAP версии 2
Протокол MS-CHAP-V2 максимально соответствует как протоколу MS-CHAP-V1, так и стандартному протоколу СНАР. Различия между про-токолами MS-CHAP-V1 и MS-CHAP-V2 следующие:
Response, на который противоположная сторона отвечает в пакете Success."Windows NT compatible challenge response" изменено в пакете Response включением вызова противоположной стороны и имени пользователя."LAN Manager compatible challenge re-sponse" всегда посылалось в пакете Response. В MS-CHAP-V2 данное поле заменено на поле Peer-Challenge.Message в пакете Failure.Change Password версий 1 и 2 больше не поддерживаются. Они заменены единым пакетом Change-Password.Конфигурация LCP
Конфигурация LCP аналогична той, которая используется в стандартном СНАР, за исключением того, что поле Algorithm имеет значение 0x81, а не значение 0x05 (MD5). Реализации РРР, которые не поддерживают MS-CHAP-V2, но корректно реализуют LCP Config-Rej, не имеют проблем с подобной нестандартной опцией.
Пакет Challenge
Пакет Challenge в протоколе MS-CHAP-V2 имеет тот же самый формат, что и в стандартном протоколе СНАР.
Аутентифицирующая сторона посылает 16-октетный вызов в поле Value. Противоположная сторона может использовать свой алгоритм для выбора 16-октетного значения.
Пакет Response
Формат пакета Response в протоколе MS-CHAP-V2 аналогичен формату пакета Response в стандартном протоколе СНАР. Отличается только формат поля Value.
16 октетов: вызов противоположной стороны.
8 октетов: зарезервировано, должно быть установлено в ноль.
24 октета: NT-Response.
1 октет: флаги
Поле Peer-Challenge содержит созданное противоположной стороной 16-октетное случайное число. Данное случайное число используется при вычислении поля NT-Response.
Поле NT-Response является функцией от пароля, имени пользователя, содержимого поля Peer-Challenge и содержит результат функции GenerateNTResponse(). Пароль Windows является строкой длины от 0 до 256 чувствительных к регистру символов Unicode. При вычислении значения поля NT-Response используется только имя пользователя без имени соответствующего домена, не зависимо от того, присутствует ли имя домена в поле Name или нет.
Поле Name является строкой длиной от 0 до 256 чувствительных к регистру символов ASCII, которые являются именем пользователя.
Пакет Success
Формат пакета Success аналогичен формату пакета Success в стандартном протоколе СНАР. Однако поле Message содержит строку ответа длиной 42 октета и сообщение в печатаемом формате. Формат данного поля следующий:
S=<auth_string> M=<message>
<auth_string> состоит из 20 октетов чисел, представленных в коди-ровке ASCII в виде 40 шестнадцатеричных чисел. Данное значение получено из вызова в пакете Challenge, полей Peer-Challenge и NT-Response из пакета Response, пароля противоположной стороны. Данное значение является результатом функции GenerateAuthenticatorResponse(). Аутентификатор проверяется при получении пакета Success. Если аутентификатор отсутствует или не корректный, противоположная сторона завершает сессию.
Пакет Failure
Формат пакета Failure аналогичен формату пакета Failure в стандартном протоколе СНАР. Однако текст хранится в поле Message, значение которого, в отличие от стандартного протокола СНАР, не влияет на операции протокола. Формат поля Message следующий:
E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=<msg>
Где "eeeeeeeeee" представление в ASCII десятичного кода ошибки (не более 10 цифр), соотвествующего одному из перечисленных:
646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD
Если установлен флаг "r", то допускается повтор, в противном случае повтор не допускается. Установка флага "r" означает, что на аутентифицирующей стороне отключены все короткие таймауты и предполагается, что противоположная сторона предложит пользователю ввести новый креденциал и повторит ответ.
"cccccccccccccccccccccccccccccccc" является представлением в ASCII шестнадцатеричного значения вызова. Данное поле всегда присутствует и имеет длину 32 октета.
"vvvvvvvvvv" является представлением в ASCII кода версии, который указывает на то, что сервер поддерживает протокол изменения пароля. Для протокола MS-CHAP-V2 данное значение должно быть равно 3.
<msg> является текстом в соответствующей кодировке и языке.
Пакет Change-Password
Пакет Change-Password не поддерживается ни стандартным протоколом СНАР, ни протоколом MS-CHAP-V1. Данный пакет позволяет противоположной стороне изменить пароль, указанный в предыдущем пакете Response. Пакет Change-Password должен посылаться только если аутентифицирующая сторона присылает ERROR_PASWD_EXPIRED в поле Message пакета Failure.
Формат данного пакета следующий:
| Длина поля | Название поля | Примечание |
|---|---|---|
| 1 октет | ||
| 1 октет | Identifier | Данное поле позволяет определить пары запросов и ответов. |
| 2 октета | ||
| 516 октетов | Encrypted-Password | Данное поле содержит результат выполнения функции NewPasswordEncruptedWithOldNtPasswordHash(). |
| 16 октетов | Encrypted-Hash | Данное поле содержит результат выполнения функции OldNtPasswordHashEncryptedWithNewNtPasswordHash(). |
| 16 октетов | Peer-Challenge | 16-октетное случайное число, аналогичное случайному числу в пакете Response. |
| 8 октетов | | Зарезервировано. |
| 24 октета | NT-Response | Аналогично соответствующему полю в пакете Response, но вычисленное для нового пароля и вызова, полученного в пакете Failure. |
| 2 октета | | Флаги. |
После завершения выполнения LCP-протокола должен быть сконфигурирован протокол сетевого уровня, такой как IP, IPX и т.п. Конфигурирование протокола сетевого уровня выполняется протоколом управления сетью (Network Control Protocol – NCP).
После того, как протокол NCP перейдет в открытое состояние, РРР начинает передачу пакетов соответствующего протокола сетевого уровня. В данном состоянии трафик на канальном уровне состоит из комбинации пакетов LCP, NCP и протокола сетевого уровня
Протокол предназначен для шифрования РРР-пакетов. В протоколе ис-пользуется поточный алгоритм шифрования RC4. О длине ключа ведутся переговоры. МРРЕ (Microsoft Point-to-Point Encryption) поддерживает 40-битные, 56-битные и 128-битные ключи. Ключи сессии меняются часто, частота смены ключей зависит от установленных опций.
Инициатор переговоров указывает в опциях все алгоритмы, которые он поддерживает.
(рис 5.7) Переговоры об используемой длине ключа
Получатель отвечает сообщением с кодом NAK с единственной установленной опцией. Если Получатель поддерживает несколько алгоритмов шифрования, то указывается наиболее сильный. Затем Инициатор должен либо послать другой запрос, содержащий ту же самую опцию, что и в сообщении NAK Получателя, либо прервать переговоры, сбрасывая соединение.
(рис 5.8) Завершение переговоров об используемой длине ключа
Для того, чтобы передавать МРРЕ-пакеты, протокол РРР должен перейти в состояние пересылки дейтаграмм сетевого уровня. В информаци-онное поле РРР инкапсулируется одна МРРЕ-дейтаграмма. Для всех зашифрованный дейтаграмм в поле Protocol указан тип 0х00FD.
(рис 5.9) Обмен зашифрованными дейтаграммами в протоколе РРР
Протокол управления IP (Internet Protocol Control Protocol – IPCP) предназначен для конфигурирования IP-протокола на обоих концах канала точка-точка. IPCP использует тот же самый механизм обмена пакетами, что и протокол управления каналом LCP. Обмен IPCP-пакетами начинается в состоянии обмена дейтаграммами сетевого уровня. IPCP отличается от LCP следующим:
Configure-Request – запрос конфигурации.Configure-Ack – подтверждение на запрос конфигурации.Configure-Nak – негативное подтверждение.Configure-Reject – отклонение конфигурацию.Terminate-Request – завершение запроса.Terminate-Ack – подтверждение завершения.Code-Reject – код отклонения. Перед тем, как посылать любые IP-пакеты, протокол IPCP должен перейти в открытое состояние. Максимальная длина IP-пакета, передаваемого по РРР-каналу, та же самая, что и максимальная длина информационного поля РРР-данных канального уровня. IP-дейтаграммы большего размера будут фрагментированы. Если необходимо избежать фрагментирования и последующего сбора пакетов, то следует использовать опции ТСР Maximum Segment Size и MTU discovery.
Конфигурационные опции IPCP позволяют вести переговоры о требуемых параметрах IP. IPCP использует тот же самый формат конфигурацион-ных опций, что и LCP.
(рис 5.10) Задание диапазона IP-адресов, которые будут выдаваться клиенту
Данный параметр позволяет договориться об использовании конкрет-ного протокола сжатия. По умолчанию сжатие не требуется.
.Данный параметр предоставляет способ ведения переговоров об IP-адресе, который будет назначен локальной стороне канала. Он позволяет отправителю Configure-Request указать желаемый IP-адрес или запросить противоположную сторону выдать ему IP-адрес. Противоположная сторона может предоставить данную информацию в параметре Nak, указав IP-адрес, который будет использоваться.
Могут быть указаны IP-адреса первичного и вторичного DNS-серверов. Возможность использования информации об адресах DNS-серверов зависит от топологии удаленной сети и от приложения на локальной стороне.
Параметры позволяют договориться об IP-адресах первичного и вторичного DNS-серверов, которые будут использоваться на локальной стороне.
(рис 5.11) Назначение IP-адреса клиенту
Существуют различные способы инкапсуляции одного протокола в другой. Рассмотрим протокол GRE (Generic Routing Encapsulation), который позволяет инкапсулировать любой протокол. Это может быть использовано для любых целей.
Будем считать, что имеется пакет, который необходимо инкапсулировать и доставить некоторому получателю. Этот пакет будет являться содержимым GRE-пакета. Получившийся GRE-пакет затем инкапсулируется в пакет некоторого другого протокола, и отправляется. Будем называть этот внешний протокол протоколом доставки.
Результирующий пакет имеет следующий формат:
(рис 5.1) Формат GRE-пакета
В GRE-заголовке содержится тип инкапсулированного протокола. Если содержимым пакета является IPv4, то тип протокола должен быть 0х800.
Когда конечная точка туннеля декапсулирует GRE-пакет, у которого содержимым является пакет IPv4, адрес получателя в заголовке содержи-мого пакета может использоваться для дальнейшей доставки пакета. Долж-на выполняться проверка, что адрес получателя во вложенном пакете не равен адресу в инкапсулирующем пакете, так как это является другим концом туннеля, и в этом случае происходит зацикливание.
В качестве протокола доставки может также использоваться протокол IPv4.
(рис 5.2) Протокол GRE
Virtual Private Network (VPN) – это различные технологии, которые позволяют создавать логические сети, использующие в качестве транспорта другие сетевые протоколы. При этом характеристики безопасности созданной логической сети могут отличаться от характеристик безопасности сети, которая используется в качестве транспорта. Такие сети могут создаваться на разных уровнях стека OSI исходной транспортной сети. Создаваемая логическая сеть не обязательно должна быть маршрутизируемой, она может обеспечивать соединение типа точка-точка.
VPN используются в двух основных сценариях:
При создании VPN всегда следует помнить, что безопасность компьютерной системы и сетевого трафика зависит от многих факторов. Развертывание VPN с использованием той или иной технологии является только частью комплексного подхода к обеспечению безопасности.
Безопасность, обеспечиваемая VPN, зависит от многих параметров операционного окружения, в котором VPN выполняется. Например, от безопасности ОС, источника случайных чисел, способов управления системой и т.д.
Рассмотрим основные протоколы создания VPN и проанализируем их характеристики с точки зрения безопасности создаваемых соединений, возможностей масштабирования и наличия каких-либо дополнительных возможностей.
Таблица 5.1
Терминология
Протокол РРР определяет механизм инкапсуляции для пересылки пакетов, принадлежащих любым сетевым протоколам, по каналам точка-точка 2 уровня. Обычно пользователь получает соединение канального уровня (так называемое L2-соединение) к Network Access Server (NAS), используя одну из технологий доступа типа точка-точка: dial-up POTS, ISDN, ADSL и т.п. Протокол РРР выполняется поверх данного соединения. В простейшем случае завершение L2-соединения и конечная точка РРР-протокола расположены на одном и том же физическом устройстве NAS.
L2TP расширяет возможности РРР, допуская, чтобы конечные точки L2 и РРР были расположены на разных устройствах, соединенных между собой сетью, по которой могут передаваться пакеты. При использовании L2TP пользователь создает L2-соединение с концентратором (например, модемом, ADSL DSLAM и т.п.), затем концентратор туннелирует отдельные РРР-кадры к NAS. Это позволяет обрабатывать РРР-кадры отдельно от точки завершения L2-соединения.
Одно очевидное преимущество такого разделения состоит в том, что вместо требования завершения L2-соединения на NAS (что может требовать тянуть провода на большие расстояния), соединение может заканчиваться на локальном концентраторе, который создает логическую РРР-сессию поверх разделяемой инфраструктуры такой, как frame relay или интернет. С точки зрения пользователя не существует различия между завершением L2 непосредственно на NAS или использованием L2TP.
Протокол L2TP определяет создание туннелей между двумя узлами и последующую инкапсуляцию туннелируемых РРР сессий.
В протоколах, выполняющих пересылку РРР-данных по сети Ethernet, используется следующая терминология.
| L2TP концентратор доступа (L2TP Access Concentrator - LAC) | Узел, который является одной из конечных точек L2TP-туннеля. LAC является противоположной сто-роной L2TP сетевого сервера (LNS). LAC расположен между LNS и удаленной системой и перенаправляет пакеты к каждой из них. Пакеты, посылаемые от LAC к LNS, туннелируются по протоколу L2TP. Соедине-ние между LAC и удаленной системой является либо локальным, либо выполняется по протоколу РРР. Если вместо L2TP используется протокол РРТР, то аналогичный узел называется РРТР концентратор доступа – РАС. |
| L2TP сетевой сервер (L2TP Network Server - LNS) | Узел, который является одной из конечных точек L2TP-туннеля. LNS является противоположной стороной LAC. LNS является логической конечной точкой РРР-сессии, которая туннелируется от удаленной системы с помощью LAC. LNS также является конечной точкой туннеля между LNS и LAC. Если вместо L2TP используется протокол РРТР, то аналогичный узел называется РРТР сетевой сервер – PNS. |
| Сервер сетевого доступа (NAS) | Устройство, предоставляющее пользователям сетевой доступ по требованию. Этот доступ является доступом типа точка-точка, использующим PSTN или ISDN каналы. Функции NAS может выполнять и LAC, и LNS. |
| L2TP/PPTP-туннель | Туннель между LAC и LNS. Туннель состоит из управляющего соединения и нуля или более L2TP-сессий. L2TP/PPTP-туннель передает инкапсулированные дейтограммы PPP и управляющие сообщения между LAC и LNS. |
| L2TP/PPTP-сессия | В протоколах РРТР и L2TP определено понятие сес-сии. LNS и LAC поддерживают состояние для каждого вызова, который инициирован LAC или на который ответил LAC. L2TP-сессия создается между LAC и LNS, когда РРР-соединение установлено между удаленной системой и LNS. Дейтаграммы, относящиеся к РРР-соединению, посылаются по туннелю между LAC и LNS. Между установленными сессиями и соответствующими вызовами существует взаимнооднозначное соответствие. |
| Управляющее соединение L2TP/PPTP | Управляющее соединение используется для установ-ление и поддержки как для сессий, так и самого L2TP/PPTP-туннеля и создается для каждой пары LАС, LNS. Управляющее соединение определяет все характеристики туннеля и связанных с ним сессий. |
Обзор
Протокол РРР предназначен для создания не маршрутизируемых каналов, по которым передаются пакеты между двумя участниками. Каналы являются полнодуплексными и функционируют в обоих направлениях.
Протокол обеспечивает инкапсуляцию различных протоколов сетевого уровня в один канал.
Протокол РРР определяет способ передачи дейтаграмм по последова-тельным каналам. Протокол РРР состоит из следующих протоколов:
Для согласования параметров канала используется протокол управления каналом LCP. Протокол LCP может также выполнять аутентификацию конечных точек канала.
В РРР-каналах необходимо задавать многие параметры маршрутизируемых сетевых протоколов. Например, назначение и управление IP-адресами. Для решения этих проблем используются протоколы управления сетью NCP.
Конфигурирование выполняется с помощью переговоров об используемом наборе опций. Для этого каждая сторона канала описывает противоположной стороне свои возможности и требования.
Для того, чтобы установить соединение точка-точка, каждый конец РРР-канала должен во-первых послать LCP-пакеты для конфигурирования и тестирования канала данных. После того, как канал установлен и выпол-нены переговоры о дополнительных опциях, которые необходимы LCP, РРР должен послать NCP-пакеты для выбора и конфигурирования прото-колов сетевого уровня. После того, как протокол сетевого уровня сконфигурирован, по каналу могут посылаться дейтаграммы.
Канал будет оставаться открытым до тех пор, пока явно не будет закрыт LCP- или NCP-пакетами, или пока не произойдет какое-нибудь внешнее событие.
Диаграмма состояний
В течение своего жизненного цикла РРР-канал проходит через следующие состояния.
(рис 5.3) Диаграмма состояний РРР-канала
Установление канала
Для установления соединения используется LCP-протокол, в котором выполняется обмен конфигурационными пакетами. Инициализация канала выполняется с помощью пакета Configure-Request, на который получатель отвечает Configure-Ack. Инициализация канала завершается, и состояние LCP становится открытым после того, как пакет Configure-Ack отправлен и получен.
Протоколом LCP конфигурируются только те опции, которые не зависят от конкретных протоколов сетевого уровня. Конфигурированием протоколов сетевого уровня занимается отдельные протоколы управления сетью (NCP).
Любые не-LCP-пакеты, полученные в этом состоянии, отбрасываются.
Получатель LCP-запроса на конфигурацию переходит в состояние пересылки дейтаграмм сетевого уровня после инициализации канала и выполнения аутентификации.
(рис 5.4) Пример LCP-запроса
(рис 5.5) Пример запроса на аутентификацию
Аутентификация
В некоторых случаях перед обменом пакетами протокола сетевого уровня может требоваться аутентификация противоположной стороны.
Аутентификация должна иметь место сразу же после установления канала.
Переход из состояния аутентификации в состояние пересылки дейтаграмм сетевого уровня не происходит до тех пор, пока аутентификация не завершиться.
(рис 5.6) СНАР- аутентификация в протоколе РРР
Протокол СНАР используется для периодической проверки аутентификации противоположной стороны с помощью трех шагового рукопожатия. Протокол выполняется при начальном установлении канала и может повторяться в любое время после того, как канал установлен.
Преимущества
СНАР обеспечивает защиту от replay-атак, если в качестве запроса по-сылается случайное значение.
Данный метод аутентификации основан на том, что оба участника знают некий секрет, который никогда не посылается по каналу.
Хотя аутентифицируется только одна сторона, СНАР-переговоры можно вести в обоих направлениях с тем же самым секретом, обеспечивая взаимную аутентификацию.
Так как данный протокол может использоваться для аутентификации многими различными системами, поле name может использоваться для нахождения нужного секрета. С помощью данного поля можно также поддерживать несколько пар name/secret для каждой системы.
Недостатки
Требуется, чтобы секрет был доступен в незашифрованном виде. Секрет, хранящейся в базе данных в виде результата применения односторонней функции, не может использоваться.
Это неудобно при большом количестве участников, так как каждый секрет должен храниться на обоих концах канала.
Чтобы избежать посылки секрета по другим каналам в сети, рекомендуется, чтобы значения запроса и ответа проверялись на центральном сервере, а не каждым сервером сетевого доступа. В противном случае секрет должен будет посылаться этим серверам в зашифрованном виде. Также требуется определенная форма доверия участников друг другу.
Требования разработки
Предпочтительнее, чтобы секрет был примерно той же длины, что и значение хэша используемой хэш-функции. Например, 16 октетов для MD5. Используемая хэш-функция должна гарантировать, что вычислительно сложно определить секрет, зная запрос и ответ.
Каждый запрос является уникальным, так как повторное использование предыдущего значения запроса позволит атакующему ранее перехваченный ответ.
Формат конфигурационного параметра
Формат конфигурационного параметра протокола Аутентификации следующий:
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Algorithm | +-+-+-+-+-+-+-++-+ Type 3 Length 5 Authentication Protocol c223 Algorithm
определяет используемый алгоритм. Значения алгоритмов определяются IANA. Для MD5 значением является 5.
Формат пакета
В информационное поле РРР-кадра инкапсулируется ровно один СНАР-пакет.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Code | Identifier | Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Data ... +-+-+-+-+
Code определяет тип СНАР-пакета.
1 Запрос
2 Ответ
3 Успех
4 Неуспех
Identifier используется для определения пар соответствующих запросов и ответов.
Length определяет длину СНАР-пакета.
Data формат данного поля определяется полем Code.
Пакет Challenge используется в качестве первого пакета протокола СНАР. Аутентифицирующая сторона посылает СНАР-пакет с полем Code, установленным в 1 (Challenge). Могут посылаться дополнительные пакеты Challenge до тех пор, пока не будет получен пакет Response или не истечет счетчик повторов.
Пакет Challenge также может передаваться в любое время в течение выполнения протокола сетевого уровня, чтобы гарантировать, что не было подмены участников соединения.
Противоположная сторона ожидает пакеты Challenge в течение фаз аутентификации и протокола сетевого уровня. После получения пакета Challenge участник посылает СНАР-пакет и полем Code, установленным в 2 (Response).
После того, как пакет Response получен, аутентифицирующая сторона сравнивает значение, полученное в ответе, с собственным вычисленным значением. В зависимости от результата аутентифицирующая сторона посылает либо пакет Success, либо пакет Failure.
Следует понимать, что, так как пакет Success может быть потерян, аутентифицирующая сторона повторяет пакеты Response в течение вы-олнения протокола сетевого уровня после завершения фазы аутентификации. Все пакеты Response, полученные в любой другой фазе, отбрасываются без отправления ответа.
Если пакет Failure потерян, аутентифицирующая сторона завершает соединение, и пакеты Terminate-Request и Terminate-Ack протокола сетевого уровня обеспечивают альтернативный способ определения, что аутентификация была неудачной.
Поле Identifier изменяется в каждом новом пакете Challenge. Поле Identifier в пакете Response копируется из поля Identifier соответствующего пакета Challenge.
В поле Data содержатся значения Value и Name. Значение Value в пакете Challenge должно быть уникальным и не зависеть от секрета. Значение Value в пакете Response является результатом вычисления хэш-функции от следующих значений: Identifier, secret, значение Value из пакета Challenge.
В поле Name записана идентификация системы, которая послала пакет. В этом случае синтаксис может быть любой, как строка символов ASCII, так и уникальный идентификатор в ASN.1 синтаксисе.
Обсуждение безопасности
Не существует особых требований, как и когда должна выполняться повторная попытка при неудачной аутентификации. Тем не менее, в протоколе сетевого уровня может в любой момент начаться протокол аутентификации. Считается, что счетчик неудачных попыток аутентификации не должен сбрасываться до тех пор, пока не будет выполнена успешная аутентификация или не сброшено соединение.
Не существует требования, чтобы аутентификация была взаимной или что в обоих направлениях должен выполняться один и тот же протокол.
Расширения Microsoft РРР СНАР версии 1
Обзор
Microsoft разработал протокол MS-CHAP для аутентификации удаленных рабочих станций, который с одной стороны имел бы привычную для локальных пользователей функциональность, а с другой стороны использовал бы алгоритмы шифрования и хэширования.
MS-CHAP основан на протоколе СНАР. Различия между этими протоколами следующие:
Конфигурирование LCP
Конфигурирование LCP для MS-CHAP аналогично конфигурированию стандартного СНАР, за исключением того, что поле Algorithm имеет значение 0x80, а не 0x05. Реализации РРР, который не поддерживают MS-CHAP, но корректно реализуют LCP Config-Rej, не должны иметь проблем с данным нестандартным параметром.
Пакет Challenge
Пакет Challenge в протоколе MS-CHAP аналогичен пакету Challenge в стандартном протоколе СНАР.
Аутентифицирующая сторона посылает 8-октетное значение в поле Value.
Пакет Response
Формат пакета Response аналогичен формату пакета Response в стандартном протоколе СНАР. Однако поле Value отличается:
Совместимый с LAN Manager ответ является результатом выполнения функции LmChallengeResponse()от пароля и полученного запроса. Пароль LAN Manager не может быть длиннее 14 символов и чувствителен к регистру.
Совместимый с Window NT ответ является результатом выполнения функции NTChallengeResponse()от пароля и полученного запроса. Пароль Windows NT является строкой от 0 до 256 символов Unicode, пароль чувствителен к регистру. Обычно длина пароля в Windows NT ограничена 14 символами.
Если установлен флаг "Используется совместимость ответа с Windows NT", то используется Windows NT ответ. Ответ "LAN Manager" может ис-пользоваться, если аккаунт не имеет хэша пароля Windows NT, например, еасли пароль не был изменен после загрузки из базы данных аккаунтов LAN Manager 2.x. Если флаг установлен, то ответ Windows NT игнорирует-ся и используется ответ LAN Manager.
Поле Name содержит имя пользовательского аккаунта противоположной стороны. Имя домена Windows NT может являться префиксом имени пользователя.
Пакет Success
Формат пакета Success аналогичен формату стандартного пакета Success в СНАР.
Пакет Failure
Формат пакеты Failure аналогичен формату стандартного пакета Failure в протоколе СНАР. Однако, в отличии от стандартных правил СНАР, содержимое поля Message влияет на протокол. Формат поля Message следующий:
E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv
Где "eeeeeeeeee" есть десятичный код ошибки, который может быть одним из следующих значений:
646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD
Если установлен флаг "r", то возможна повторная попытка, если флаг не установлен, то повторная попытка не допускается. Если аутентифицирующая сторона устанавливает данный флаг в 1, она отключает короткие таймауты, предполагая, что противоположная сторона предложит пользователю ввести новые креденциалы и повторить ответ.
"cccccccccccccccc" является новым значением вызова (challenge). Данное поле не является обязательным. Если оно не посылается, то аутентифицирующая сторона считает, что повторный ответ будет вычислен с использованием предыдущего значения вызова, к которому прибавлено десятичное число 23.
10 цифр "vvvvvvvvvv" содержат код версии, обозначающий версию протокола MS-CHAP, поддерживаемую сервером. Это важно только при выборе пакета Change Password. Если поле отсутствует, то считается, что используется версия 1.
Пакет Change Password
Пакет Change Password не посылается в стандартном протоколе СНАР. Допускается, чтобы противоположная сторона изменила пароль аккаунта, указанного в последнем пакете Response. В версии 1 пакет Change Password должен посылаться только в том случае, если аутенти-фицирующая сторона возвратила ERROR_PASSWD_EXPIRED.
Обсуждение безопасности
Аутентифицирующая сторона должна ограничить число попыток ввода пароля, чтобы предотвратить атаки, связанные с перебором паролей. Так как пароль скрывается с помощью хэш-функции, то возможность взлома пароля зависит от криптографической стойкости используемой хэш-функции. Также необходимо достаточно часто менять пароль.
Расширения Microsoft PPP CHAP версии 2
Протокол MS-CHAP-V2 максимально соответствует как протоколу MS-CHAP-V1, так и стандартному протоколу СНАР. Различия между про-токолами MS-CHAP-V1 и MS-CHAP-V2 следующие:
Response, на который противоположная сторона отвечает в пакете Success."Windows NT compatible challenge response" изменено в пакете Response включением вызова противоположной стороны и имени пользователя."LAN Manager compatible challenge re-sponse" всегда посылалось в пакете Response. В MS-CHAP-V2 данное поле заменено на поле Peer-Challenge.Message в пакете Failure.Change Password версий 1 и 2 больше не поддерживаются. Они заменены единым пакетом Change-Password.Конфигурация LCP
Конфигурация LCP аналогична той, которая используется в стандартном СНАР, за исключением того, что поле Algorithm имеет значение 0x81, а не значение 0x05 (MD5). Реализации РРР, которые не поддерживают MS-CHAP-V2, но корректно реализуют LCP Config-Rej, не имеют проблем с подобной нестандартной опцией.
Пакет Challenge
Пакет Challenge в протоколе MS-CHAP-V2 имеет тот же самый формат, что и в стандартном протоколе СНАР.
Аутентифицирующая сторона посылает 16-октетный вызов в поле Value. Противоположная сторона может использовать свой алгоритм для выбора 16-октетного значения.
Пакет Response
Формат пакета Response в протоколе MS-CHAP-V2 аналогичен формату пакета Response в стандартном протоколе СНАР. Отличается только формат поля Value.
16 октетов: вызов противоположной стороны.
8 октетов: зарезервировано, должно быть установлено в ноль.
24 октета: NT-Response.
1 октет: флаги
Поле Peer-Challenge содержит созданное противоположной стороной 16-октетное случайное число. Данное случайное число используется при вычислении поля NT-Response.
Поле NT-Response является функцией от пароля, имени пользователя, содержимого поля Peer-Challenge и содержит результат функции GenerateNTResponse(). Пароль Windows является строкой длины от 0 до 256 чувствительных к регистру символов Unicode. При вычислении значения поля NT-Response используется только имя пользователя без имени соответствующего домена, не зависимо от того, присутствует ли имя домена в поле Name или нет.
Поле Name является строкой длиной от 0 до 256 чувствительных к регистру символов ASCII, которые являются именем пользователя.
Пакет Success
Формат пакета Success аналогичен формату пакета Success в стандартном протоколе СНАР. Однако поле Message содержит строку ответа длиной 42 октета и сообщение в печатаемом формате. Формат данного поля следующий:
S=<auth_string> M=<message>
<auth_string> состоит из 20 октетов чисел, представленных в коди-ровке ASCII в виде 40 шестнадцатеричных чисел. Данное значение получено из вызова в пакете Challenge, полей Peer-Challenge и NT-Response из пакета Response, пароля противоположной стороны. Данное значение является результатом функции GenerateAuthenticatorResponse(). Аутентификатор проверяется при получении пакета Success. Если аутентификатор отсутствует или не корректный, противоположная сторона завершает сессию.
Пакет Failure
Формат пакета Failure аналогичен формату пакета Failure в стандартном протоколе СНАР. Однако текст хранится в поле Message, значение которого, в отличие от стандартного протокола СНАР, не влияет на операции протокола. Формат поля Message следующий:
E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=<msg>
Где "eeeeeeeeee" представление в ASCII десятичного кода ошибки (не более 10 цифр), соотвествующего одному из перечисленных:
646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD
Если установлен флаг "r", то допускается повтор, в противном случае повтор не допускается. Установка флага "r" означает, что на аутентифицирующей стороне отключены все короткие таймауты и предполагается, что противоположная сторона предложит пользователю ввести новый креденциал и повторит ответ.
"cccccccccccccccccccccccccccccccc" является представлением в ASCII шестнадцатеричного значения вызова. Данное поле всегда присутствует и имеет длину 32 октета.
"vvvvvvvvvv" является представлением в ASCII кода версии, который указывает на то, что сервер поддерживает протокол изменения пароля. Для протокола MS-CHAP-V2 данное значение должно быть равно 3.
<msg> является текстом в соответствующей кодировке и языке.
Пакет Change-Password
Пакет Change-Password не поддерживается ни стандартным протоколом СНАР, ни протоколом MS-CHAP-V1. Данный пакет позволяет противоположной стороне изменить пароль, указанный в предыдущем пакете Response. Пакет Change-Password должен посылаться только если аутентифицирующая сторона присылает ERROR_PASWD_EXPIRED в поле Message пакета Failure.
Формат данного пакета следующий:
| Длина поля | Название поля | Примечание |
|---|---|---|
| 1 октет | ||
| 1 октет | Identifier | Данное поле позволяет определить пары запросов и ответов. |
| 2 октета | ||
| 516 октетов | Encrypted-Password | Данное поле содержит результат выполнения функции NewPasswordEncruptedWithOldNtPasswordHash(). |
| 16 октетов | Encrypted-Hash | Данное поле содержит результат выполнения функции OldNtPasswordHashEncryptedWithNewNtPasswordHash(). |
| 16 октетов | Peer-Challenge | 16-октетное случайное число, аналогичное случайному числу в пакете Response. |
| 8 октетов | | Зарезервировано. |
| 24 октета | NT-Response | Аналогично соответствующему полю в пакете Response, но вычисленное для нового пароля и вызова, полученного в пакете Failure. |
| 2 октета | | Флаги. |
После завершения выполнения LCP-протокола должен быть сконфигурирован протокол сетевого уровня, такой как IP, IPX и т.п. Конфигурирование протокола сетевого уровня выполняется протоколом управления сетью (Network Control Protocol – NCP).
После того, как протокол NCP перейдет в открытое состояние, РРР начинает передачу пакетов соответствующего протокола сетевого уровня. В данном состоянии трафик на канальном уровне состоит из комбинации пакетов LCP, NCP и протокола сетевого уровня
Протокол предназначен для шифрования РРР-пакетов. В протоколе ис-пользуется поточный алгоритм шифрования RC4. О длине ключа ведутся переговоры. МРРЕ (Microsoft Point-to-Point Encryption) поддерживает 40-битные, 56-битные и 128-битные ключи. Ключи сессии меняются часто, частота смены ключей зависит от установленных опций.
Инициатор переговоров указывает в опциях все алгоритмы, которые он поддерживает.
(рис 5.7) Переговоры об используемой длине ключа
Получатель отвечает сообщением с кодом NAK с единственной установленной опцией. Если Получатель поддерживает несколько алгоритмов шифрования, то указывается наиболее сильный. Затем Инициатор должен либо послать другой запрос, содержащий ту же самую опцию, что и в сообщении NAK Получателя, либо прервать переговоры, сбрасывая соединение.
(рис 5.8) Завершение переговоров об используемой длине ключа
Для того, чтобы передавать МРРЕ-пакеты, протокол РРР должен перейти в состояние пересылки дейтаграмм сетевого уровня. В информаци-онное поле РРР инкапсулируется одна МРРЕ-дейтаграмма. Для всех зашифрованный дейтаграмм в поле Protocol указан тип 0х00FD.
(рис 5.9) Обмен зашифрованными дейтаграммами в протоколе РРР
Протокол управления IP (Internet Protocol Control Protocol – IPCP) предназначен для конфигурирования IP-протокола на обоих концах канала точка-точка. IPCP использует тот же самый механизм обмена пакетами, что и протокол управления каналом LCP. Обмен IPCP-пакетами начинается в состоянии обмена дейтаграммами сетевого уровня. IPCP отличается от LCP следующим:
Configure-Request – запрос конфигурации.Configure-Ack – подтверждение на запрос конфигурации.Configure-Nak – негативное подтверждение.Configure-Reject – отклонение конфигурацию.Terminate-Request – завершение запроса.Terminate-Ack – подтверждение завершения.Code-Reject – код отклонения. Перед тем, как посылать любые IP-пакеты, протокол IPCP должен перейти в открытое состояние. Максимальная длина IP-пакета, передаваемого по РРР-каналу, та же самая, что и максимальная длина информационного поля РРР-данных канального уровня. IP-дейтаграммы большего размера будут фрагментированы. Если необходимо избежать фрагментирования и последующего сбора пакетов, то следует использовать опции ТСР Maximum Segment Size и MTU discovery.
Конфигурационные опции IPCP позволяют вести переговоры о требуемых параметрах IP. IPCP использует тот же самый формат конфигурацион-ных опций, что и LCP.
(рис 5.10) Задание диапазона IP-адресов, которые будут выдаваться клиенту
Данный параметр позволяет договориться об использовании конкрет-ного протокола сжатия. По умолчанию сжатие не требуется.
.Данный параметр предоставляет способ ведения переговоров об IP-адресе, который будет назначен локальной стороне канала. Он позволяет отправителю Configure-Request указать желаемый IP-адрес или запросить противоположную сторону выдать ему IP-адрес. Противоположная сторона может предоставить данную информацию в параметре Nak, указав IP-адрес, который будет использоваться.
Могут быть указаны IP-адреса первичного и вторичного DNS-серверов. Возможность использования информации об адресах DNS-серверов зависит от топологии удаленной сети и от приложения на локальной стороне.
Параметры позволяют договориться об IP-адресах первичного и вторичного DNS-серверов, которые будут использоваться на локальной стороне.
(рис 5.11) Назначение IP-адреса клиенту
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.