Если ваш ppp сервер использует pap

Содержание:

Файл для PAP

Файл шифров PAP очень похож на тот, который используется CHAP. Первые два
поля всегда содержат имена пользователя и сервера, третье поле хранит шифр
PAP. Когда удаленная машина посылает запрос опознания,
pppd использует запись, которая имеет поле сервера
равное локальному hostname, и поле пользователя, равное имени пользователя,
посланному в запросе. Когда опознание произойдет, pppd
выберет шифр, который будет послан с полем пользователя, приравненным к
локальному имени пользователя, и полем сервера, приравненным к удаленному
hostname.

Образец файла шифров для PAP:

# /etc/ppp/pap-secrets
#
# user          server          secret          addrs
vlager-pap      c3po            cresspahl       vlager.vbrew.com
c3po            vlager          DonaldGNUth     c3po.lucas.com

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

Имя vlager-pap в столбце имени
пользователя мы посылаем на c3po. По
умолчанию pppd выберет локальный hostname как имя
пользователя, но Вы можете также определить различные имена, давая опцию
user, сопровождаемую эти именем.

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

# pppd ... remotename c3po user vlager-pap

В четвертом поле (и всех следующих) Вы можете определить, какие адреса IP
разрешены точно, как в файле шифров CHAP. Удаленная машина затем может
запроситьь только адреса из этого списка. В типовом файле мы требуем, чтобы
c3po использовал реальный адрес IP.

Заметьте, что PAP довольно слабый опознавательный метод, и лучше
использовать CHAP, если это возможно. Я не буду здесь описывать PAP в
деталях: если Вы заинтересованы в использовании PAP, то найдете больше
сведений на pppd(8) man-странице.

12.2 Какие опции я должен использовать? (PAP/CHAP нет)

Ну, как и во всех вещах, это зависит от многого (вздох). Опции,
определенные здесь должны работать с большинством серверов.

Однако, если они не работает, ЧИТАЙТЕ ФАЙЛ-ШАБЛОН (/etc/ppp/options.tpl) и
man pppd, и поговорите со службой поддержки сервера, к которому вы
подсоединяетесь.

Вы должны также обратить внимание, что скрипты соединения, представленные
здесь также используют некоторые опции командной строки для pppd, что позволяет
более просто вносить изменения

  ______________________________________________________________________
  # /etc/ppp/options (NO PAP/CHAP)
  #
  # Чтобы pppd не уходил в фоновый режим
  -detach
  #
  # использовать линии управления модемом
  modem
  # использовать залочку портов в стиле uucp, чтобы одновременно несколько 
  # последовательных устройств не обращались к одному порту
  lock
  # использовать аппаратное управление потоком данных
  crtscts
  # сделать это соединение маршрутом по умолчанию в таблице маршрутизации
  defaultroute
  # НИЧЕГО не "escape-ить" 
  asyncmap 0
  # использовать максмальный размер передаваемого пакета в 552 байт
  mtu 552
  # использовать максмальный размер принимаемого пакета в 552 байт
  mru 552
  #
  #-------END OF SAMPLE /etc/ppp/options (no PAP/CHAP)
  ______________________________________________________________________

NextPrevious

2.3.2.6 Packet Tracer – Configuring PAP and CHAP Authentication

From year to year, Cisco has updated many versions with difference questions. The latest version is version 6.0 in 2018. What is your version? It depends on your instructor creating your class. We recommend you to go thought all version if you are not clear. While you take online test with netacad.com, You may get random questions from all version. Each version have 1 to 10 different questions or more. After you review all questions, You should practice with our online test system by go to «Online Test» link below.

Version 5.02 Version 5.03 Version 6.0 Online Assessment
Chapter 2 Exam Chapter 2 Exam Chapter 2 Exam Online Test
Next Chapter
Chapter 3 Exam Chapter 3 Exam Chapter 3 Exam Online Test
CCNA 4 Lab Activities
 2.1.2.5 Packet Tracer – Troubleshooting Serial Interfaces
 2.3.2.6 Packet Tracer – Configuring PAP and CHAP Authentication
 2.4.1.4 Packet Tracer – Troubleshooting PPP with Authentication
 2.5.1.2 Packet Tracer – Skills Integration Challenge

PPP-кадр

Каждый кадр PPP всегда начинается и завершается байтом 0x7E. Затем следует байт адреса и байт управления, которые тоже всегда равны 0xFF и 0x03, соответственно. В связи с вероятностью совпадения байтов внутри блока данных с зарезервированными флагами существует система автоматической корректировки «проблемных» данных с последующим восстановлением.

Флаг 0x7E Адрес 0xFF Управление 0x03 Данные Контрольная сумма Флаг 0x7E
1 1 1 1494 2 1

Поля «Флаг», «Адрес» и «Управление» (заголовок кадра HDLC) могут быть опущены и не передаваться, но это произойдёт, если PPP в процессе конфигурирования (используя LCP) договорится об этом. Если PPP инкапсулирован в L2TP-пакеты, то поле «Флаг» не передаётся.

13.2 Файл секретов PAP/CHAP

Если вы используете установление подлинности по pap или chap, то вы также
должны создать файл секретов. Это:

______________________________________________________________________

/etc/ppp/pap-secrets
/etc/ppp/chap-secrets
______________________________________________________________________

Для защиты они должны принадлежать пользователю root, группе root и иметь права
доступа к файлу 740.

Первое, на что надо обратить внимание насчет PAP и CHAP — то, что они
разработаны, чтобы опознавать компьютерные системы, а не пользователей.

«Оп-па!.. А какая разнаца? » слышу я ваш вопрос.

А такая что, как только ваш компьютер создал PPP соединение с сервером, ЛЮБОЙ
пользователь вашей системы может использовать это соединение — не только вы.
Именно поэтому вы можете устанавливать WAN связь, которая соединяет две LAN,
используя PPP.

PAP может требовать (а CHAP ТРЕБУЕТ) двунаправленного установления подлинности,
то есть компьютер на каждом конце соединения должен иметь правильные имя и
пароль другой стороны. Однако, большинство PPP серверов с доступом по
коммутируемым линиям, использующие PAP, этим способом НЕ пользуются.

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

Это делается, используя имя пользователя в опции name pppd. Так, если вы
должны использовать имя пользователя, выданное вам вашим ISP, добавьте строку

______________________________________________________________________

name your_user name_at_your_ISP

______________________________________________________________________

Технически, вы действительно должны использовать пользователя our_user
name_at_your_ISP для PAP, но pppd достаточно интеллектуален, чтобы
интерпретировать имя как пользователя, если это требуется для использования
PAP. Преимущество использования опции name в том, что она также является
допустимой для CHAP.

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

Также стоит заметить, что многие ISP применяют модемные пуллы, соединенные с
различными терминальными серверами — каждый со своим именем, но ДОСТУПНЫЙ с
одного (циклически переключаемого) входного номера. Следовательно может быть
очень трудно при некоторых обстоятельствах знать заранее имя удаленного
компьютера, поскольку это зависит от того, к какому терминальному серверу вы
подсоединились!

Типы аутентификации

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

Одним из главных направлений, где используется такой процесс, является подключение к Сети. Будет это проводное соединение или аутентификация WiFi — без разницы. И в том и в другом случае процессы аутентификации практически ничем не отличаются.

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

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

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

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

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

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

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

В этом случае аутентификация пользователей и представляется максимально надежной (не считая, конечно, подделок документов, хотя это достаточно сложная и трудоемкая процедура).

Требования к проектированию

Алгоритм CHAP требует, чтобы длина секрета была
не менее 1 октета. Секрет должен быть по крайней мере столь же большим и
неопределяемым как хорошо выбранный пароль. Предпочтительно, чтобы
секрет был по крайней мере длины хэш-значения при хешировании
выбранным алгоритмом (16 октетов для MD5). Это необходимо, чтобы обеспечить
достаточно большой диапазон для секрета, что позволяет защититься от атак перебора.

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

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

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

Хотя протоколы такие как CHAP не способны защитить от активных атак прослушки в реальном времени, создание уникальных непредсказуемых запросов может защитить от широкого спектра активных атак.

Hungarian[edit]

Etymologyedit

Borrowed from a Slavic (probably from a South Slavic) language. Compare Bulgarian (pop), Serbo-Croatian , Russian (pop).

Nounedit

pap (plural )

  1. (in Catholic terminology)

Declensionedit

Inflection (stem in -o-, back harmony)
singular plural
nominative
accusative
dative
instrumental
causal-final
translative
terminative
essive-formal
essive-modal
inessive
superessive
adessive
illative
sublative
allative
elative
delative
ablative
non-attributivepossessive — singular
non-attributivepossessive — plural
Possessive forms of pap
possessor single possession multiple possessions
1st person sing. papom papjaim
2nd person sing. papod papjaid
3rd person sing. papja papjai
1st person plural papunk papjaink
2nd person plural papotok papjaitok
3rd person plural papjuk papjaik

Derived termsedit

 

Compound words

  • paplak

 

Expressions

See alsoedit

  • (Calvinist or Lutheran term)
  • prédikátor (Calvinist term)
  • (Calvinist term)
  • (Calvinist term)
  • tiszteletes (Calvinist term)
  • tisztelendő (Catholic or Lutheran term)
  • (Catholic term)

Настройка файлов PPP соединения

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

PPP использует ряд файлов для соединения и установки PPP соединения.

Они отличаются по имени и расположению между версиями PPP 2.1.2 и 2.2.

Для PPP 2.1.2 файлы:

  ______________________________________________________________________
  /usr/sbin/pppd          # the PPP binary
  /usr/sbin/ppp-on        # the dialer/connection script
  /usr/sbin/ppp-off       # the disconnection script
  /etc/ppp/options        # the options pppd uses for all connections
  /etc/ppp/options.ttyXX  # the options specific to a connection on this port
  ______________________________________________________________________

Для PPP 2.2 файлы:

  ______________________________________________________________________
  /usr/sbin/pppd                  # the PPP binary
  /etc/ppp/scripts/ppp-on         # the dialer/connection script
  /etc/ppp/scripts/ppp-on-dialer  # part 1 of the dialer script
  /etc/ppp/scripts/ppp-off        # the actual chat script itself
  /etc/ppp/options                # the options pppd uses for all connections
  /etc/ppp/options.ttyXX          # the options specific to a connection on this port
  ______________________________________________________________________

В вашем каталоге /etc должен быть каталог ppp:

drwxrwxr-x   2 root     root         1024 Oct  9 11:01 ppp

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

Напечатайте его, поскольку он содержит объяснение почти всех PPP опций
(их полезно читать вместе с man pppd). Хотя вы можете использовать этот файл
как ваш базовый файл /etc/ppp/options, вероятно лучше создать ваш собственный
файл options, который не будет включать комментарии из шаблона, тогда он будет
намного короче и более легок для чтения/сопровождения.

Если вы имеете несколько последовательных линий/модемов (обычный случай для PPP
сервера), создайте общий файл /etc/ppp/options, содержащий опции, которые
являются общими для всех последовательных портов, на которых вы осуществляете
входящие/исходящие звонки и создайте индивидуальные файлы options для каждой
последовательной линии, на которой вы будете устанавливать PPP соединение с
индивидуальными установками, требуемыми для каждого порта.

Эти файлы со специфическими для портов опциями именуются options.ttyx1,
options.ttyx2 и т.д (где x — соответствующий символ для ваших последовательных
портов).

Однако, для одиночного PPP соединения, вы можете вполне спокойно использовать
файл /etc/ppp/options. В качестве альтернативы вы можете поместить все опции
как параметры непосредственно в команде pppd.

Проще сопровождать настройку, которая использует файлы /etc/ppp/options.ttySx.
Если вы используете PPP, чтобы соединяться с рядом различных мест, то вы можете
создать файлы options для каждого места в «/etc/ppp/options.место» и затем
определять файл опций как параметр для команды PPP при соединении (используя
опцию pppd «file option-file» в командной строке).

Криптоанализ и атаки

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

Анализ генерации «Challenge Response»

Атака перебором по словарю

Процедура получения «Challenge Response» создает серьезную слабость в протоколах MS-CHAP: она позволяет атакующему ускорить перебор по словарю на коэффициент 216{\displaystyle 2^{16}}, что имеет довольно внушительный эффект с учётом относительно низкой энтропии большинства паролей пользователей.

«Authenticator Challenge», «Peer Authenticator Challenge» и «UserName» предоставляются в открытом виде и их можно подслушать, а значит «Challenge Hash» может быть легко получен из общедоступной информации. Велика вероятность восстановить пароль, основываясь на том, что многие пароли образованы из слов словаря или иным образом легко угадываемы.
Прежде всего стоит отметить, что величина Z (определённая на стадии (3с)) может быть легко восстановлена. Поскольку существует только 216{\displaystyle 2^{16}} возможных вариантов Z (так как для каждого из первых двух байт в Z существует 28{\displaystyle 2^{8}} вариантов значений), и у нас есть известная пара открытый текст («Challenge Hash») — шифротекст (DESz(«Challenge Hash»)), то мы можем перебрать каждый из вариантов для Z, что раскроет последние два байта NT-хэша пароля.

Для перебора по словарю выполняется предвычисление: хэшируется каждый вероятный пароль. Результаты хэширования сортируются по двум последним байтам , а затем, когда виден обмен MS-CHAP и можно восстановить последние два байта NT-хэша (с использованием описанного выше метода), отбираются все подходящие записи из списка хэшей . Это предоставляет атакующему набор вероятных паролей, которые дают нужное значение для последних двух байтов их NT-хэша. Далее каждый из этих вариантов проверяется методом грубой силы: вычисляется его «Challenge Response» и сверяется с подслушанным значением.

Таким образом, предложенная выше оптимизированная атака работает около 216{\displaystyle 2^{16}} раз быстрее, чем стандартная атака перебора по словарю, где проверяются все пароли. Она применима как к MS-CHAPv1 так и к MS-CHAPv2. Тем не менее, такая уязвимость гораздо важнее для MS-CHAPv2, потому что в случае MSCHAPv1 легче атаковать LanManager-хэш, чем NT-хэш.

Атака полным перебором DES ключей

Алгоритм генерации «Challenge Response» является слабым звеном, даже когда пароли содержат достаточную энтропию. NT-хэш может быть восстановлен с помощью подбора двух бит третьего DES ключа, что требует 216{\displaystyle 2^{16}} вычислений, и двух полных переборов для первого и второго DES ключей. Каждый DES ключ требует 256{\displaystyle 2^{56}} испытаний, но чтобы не перебирать 256+256=257{\displaystyle 2^{56}+2^{56}=2^{57}} вариантов для первых двух ключей, можно использовать факт, что обе DES-операции шифруют один и тот же «Challenge Hash» разными ключами. Поэтому достаточно проделать лишь 256{\displaystyle 2^{56}} операции шифрования:

desKeyX = null;
desKeyY = null;
for (long i=; i<2^56; i++) {
	result = DES(keyi], plaintext);

	if (result == ciphertext1) {
		desKeyX = result;
	} else if (result == ciphertext2) {
		desKeyY = result;
	}
}

После того, как NT-хэш восстанавливается, все шифрованные сеансы могут быть прочитаны и схема аутентификации может быть взломана без каких-либо усилий. Это показывает, что даже при использовании 128-битных ключей RC4 для MPPE, протокол MS-CHAP обеспечивает лишь эквивалент 56-битной безопасности.

Анализ генерации ключей для MPPE

Протокол ослабляет 40-битные MPPE ключи, устанавливая в старшие 24 бита 64-битного RC4 ключа значение . Известно, что, если кто-либо имеет право выбирать старшие биты ключа RC4, то он может навязать пользователю слабый класс ключей для RC4. Поэтому, если разработчики MS-CHAP хотели встроить лазейку в протоколе, они могли использовать наличие префикса для ослабления RC4.

В статистических испытаниях было обнаружено, что для ключей, которые начинаются с , первый и второй байты на выходе RC4 принимают значения и с вероятностью 0,0054 и 0,0060 соответственно, что заметно больше, чем вероятность 1/256 = 0,0039, которую можно ожидать от хорошего шифра.

Методы

LEAP

Основная статья: LEAP (Lightweight Extensible Authentication Protocol)

Cisco LEAP представляет собой тип аутентификации 802.1X для беспроводных локальных сетей (WLAN), который поддерживает стойкую взаимную аутентификацию между клиентом и сервером RADIUS, используя пароль для входа в систему в качестве общего секрета. Он обеспечивает динамические для каждой сессии и для каждого пользователя ключи. Cisco LEAP поддерживает множество клиентских операционных систем, включая Microsoft Windows, Mac OS, Linux, DOS и Windows CE. Быстрый безопасный роуминг поддерживается точками доступа Cisco Aironet серии в сочетании с Cisco-совместимым клиентским устройствам. С помощью быстрого и безопасного роуминга, прошедшие проверку подлинности клиентские устройства могут перемещаться безопасно от одной точки доступа к другой без какой-либо заметной задержки во времени реассоциации. Быстрый безопасный роуминг поддерживает чувствительные к задержкам приложения, такие как беспроводная передача голоса по IP (VoIP), планирование ресурсов предприятия (ERP) или решений на базе Citrix.

EAP-TTLS

Основная статья: EAP-TTLS (Tunneled Transport Layer Security)

EAP-TTLS представляет собой метод EAP (Extensible Authentication Protocol), который инкапсулирует сеанс TLS (Transport Layer Security), состоящий из фазы рукопожатия и фазы данных. Во время фазы рукопожатия, сервер проходит проверку подлинности клиента (или и клиент, и сервер — взаимная проверка подлинности) с использованием стандартных процедур TLS, и ключевой материал генерируется для того, чтобы создать криптографически защищенный туннель для обмена информацией в последующей фазе данных. В течение фазы данных, клиент проходит аутентификацию на сервере (или и клиент, и сервер взаимно аутентифицируются) с использованием произвольного механизма аутентификации, инкапсулированного в защищенный туннель. Инкапсулированный механизм аутентификации может сам по себе быть EAP, или это могут быть другие протоколы аутентификации, такие как PAP, CHAP, MS-CHAP или . Таким образом, EAP-TTLS позволяет проводить проверку подлинности протоколов на парольной основе с уже существующими аутентификационными базами данных, в то время как обеспечивается защита этих протоколов от подслушивания, человек-в-середине и других атак. Фаза данных, кроме того, может быть использована для дополнительного, произвольного обмена данными.

Принцип работы

Можно выделить цикл, который состоит из трёх основных частей:

  1. После установления PPP-соединения и одобрения обеих сторон на подключение по CHAP-протоколу аутентификатор отправляет на узел пакет CHAP, имеющий тип Сhallenge (вызов), который содержит в себе открытый ключ.
  2. Узел на основе полученного открытого ключа и своего секрета, вычисляет хеш с помощью алгоритма хеширования MD5 и отправляет пакет CHAP, имеющий тип Response (отклик), содержащий в себе вычисленный хеш.
  3. Аутентификатор сравнивает полученное значение хеша со своим расчётом ожидаемого значения хеша. Если значения совпадают, то проверка подлинности считается успешной. При отличающихся значениях происходит разрыв соединения.

Через различные промежутки времени аутентификатор посылает новый запрос узлу, и шаги 1-3 повторяются.

История

MS-CHAP является версией протокола CHAP, разработанной компанией Microsoft в 1997 году для Windows 3.1 и Windows 95. Затем MS-CHAP был переименован в MS-CHAPv1 и заменён MS-CHAPv2 из-за недостатков безопасности протокола, основным из которых была отправка клиентом ответа, содержащего две величины: «LAN Manager Challenge Responce» и «NT Challenge Responce », — что делалось для поддержания хранимых на сервере учётных записей пользователей, созданных до появления Windows NT хэша и ещё не обновлённых. Оба значения вычислялись по одному механизму, но с использованием разных хэшей: LAN Manager и NT LAN Manager, — где первый хэш был значительно слабее второго и не обеспечивал достаточный уровень безопасности. MS-CHAPv2 был представлен в 1998 году вместе с выпуском Windows 98 и Windows NT4.0 SP4. В 1999 году Брюс Шнайер , Дэвид Вагнер и Пейтер Затко опубликовали исследование безопасности протокола MS-CHAPv2, в котором указали уязвимости протокола и методы атаки. Microsoft исключила протокол MS-CHAPv1 из использования в Windows Vista в 2007 году. C 2012 года компания Microsoft предупреждает, что использование комбинации протоколов PPTP и MS-CHAPv2 в качестве основного механизма аутентификации для VPN является небезопасным, и рекомендует использовать механизм аутентификации PEAP-MS-CHAPv2 либо использовать VPN-туннели L2TP, IKEv2, SSTP в связке с протоколами MS-CHAPv2 или EAP-MS-CHAPv2.

Запрос и ответ

Пакет запрос используется для запуска протокола. Аутентификатор должен передавать CHAP пакет с полем кода установленным на 1 (запрос). Дополнительные запросы должны отправляться, пока не будет получен валидный ответ.

Узел ожидает пакет запроса. Всякий раз, когда вызов пакет получен, узел должен передать CHAP пакет с кодом поля установленным на 2 (Ответ).

Всякий раз, когда пакет ответа будет получен, аутентификатор сравнивает значение. На основе этого сравнения, аутентификатор должен послать пакет Success или Failure.

Краткое описание формата запроса и ответного пакета показано ниже. Поля передаются слева направо.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Value-Size   |  Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

 1 для Запроса
 2 для Ответа

Identifier

Длина поля — один октет. Идентификатор ответа копируется из поля идентификатора запроса.

Value-Size

Длина поля — один октет.

Value

Длина поля — один или более октетов. Наиболее значащие октеты передаются в первую очередь.

Name

Поле Name длинной один или более октетов представляет собой идентификацию системы, передающей пакет.

Практическое использование

1) Устанавливаем необходимые пакеты

2) Добавляем PAM-модуль с поддержкой ГОСТов

3) Устанавливаем пакет с librtpkcs11ecp.so

4) Проверяем, что Рутокен ЭЦП 2.0 работает в системе

5) Считываем сертификат

  • выводится информация о ключах и сертификатах, то необходимо считать сертификат и сохранить на диск. Для этого выполните следующую команду, где вместо {id} нужно подставить ID-сертификата, который вы увидели в выводе предыдущей команды:
    В случае если файл cert.crt создан переходим к пункту 6).
  • нет ничего, значит устройство пустое. Обратитесь к администратору или создайте ключи и сертификат самостоятельно, следуя следующему пункту.

5.1) Создаём тестовый сертификат

Путь гика (через консоль и, возможно, компилятор)

Проверьте версию OpenSC ветку pkcs11-tool с поддержкой ГОСТ-2012коммита 8cf1e6f Для удобства, можно воспользоваться онлайн-сервисом конвертации строки в ASCII-кодыУстановка и настройка OpenSSLвотвот вот

6) Регистрируем сертификат в системе

7) Настраиваем аутентификацию

  • required (требуемый): такие модули должны вернуть положительный ответ. Если результат вызова модуля содержит отрицательный ответ, это приведёт к ошибке аутентификации. Запрос будет сброшен, но остальные модули будут вызваны.
  • requisite (необходимый): похож на required, но сразу же приводит к сбою аутентификации и игнорирует остальные модули.
  • sufficient (достаточный): если перед таким модулем ни один из модулей required или sufficient не вернул отрицательного результата, то модуль вернёт положительный ответ. Оставшиеся модули будут проигнорированы.
  • optional (дополнительный): если в стеке нет модулей required и ни один из модулей sufficient не вернул положительного результата, то хотя бы один из модулей optional должен вернуть положительный ответ.

Rutoken PAM GOSTOK

8) Проверяем настройку

9) Настраиваем блокировку компьютера при извлечении токена

Для различных дистрибутивов Линукс, команда которая вызывает блокировку учетной записи при извлечении смарт-карт или токена будет отличаться. См. .

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

MS-CHAP v.2

Семейство операционных систем Windows Server 2003 включает поддержку протокола Microsoft Challenge Handshake Authentication Protocol версии 2 (MS-CHAP v2), который лучше обеспечивает безопасность подключений удаленного доступа. MS-CHAP v2 устраняет некоторые недостатки MS-CHAP версии 1, как показано в следующей таблице

Проблема протокола MS-CHAP версии 1 Решение протокола MS-CHAP версии 2
Шифрование ответа LAN Manager, применяемое для обратной совместимости со старыми клиентами удаленного доступа Microsoft, криптографически уязвимо. MS-CHAP v2 больше не разрешает использовать шифрованные ответы LAN Manager.
Шифрование изменения пароля LAN Manager криптографически уязвимо. MS-CHAP v2 больше не разрешает использовать шифрованные изменения пароля LAN Manager.
Возможна только односторонняя проверка подлинности. Клиент удаленного доступа не может проверить, подключается ли он к серверу удаленного доступа своей организации или к маскирующемуся серверу. MS-CHAP v2 обеспечивает двустороннюю проверку подлинности, называемую также взаимной проверкой подлинности. Клиент удаленного доступа получает подтверждение, что сервер удаленного доступа, к которому он пытается подключиться, имеет доступ к паролю пользователя.
При использовании 40-битного шифрования ключ шифрования основан на пароле пользователя. Всякий раз, когда пользователь подключается с одним и тем же паролем, создается один и тот же ключ шифрования. В MS-CHAP v2 ключ шифрования всегда основан на пароле пользователя и произвольной строке запроса. Каждый раз, когда пользователь подключается с одним и тем же паролем, создаются разные ключи шифрования.
Для данных, пересылаемых по подключению в обоих направлениях, используется единый ключ шифрования. При использовании протокола MS-CHAP v2 создаются отдельные ключи шифрования для приема и передачи данных.
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector