Персональный
сайт
Игоря
Сысоева


 
english
обо мне
 
sysoev.ru
 
nginx
 
mod_accel
mod_realip
mod_deflate
программирование
всякая всячина
windows
freebsd
apache
pppd
unix
web
 
 

Аутентификация PAP и CHAP

 

24.08.1999

Поскольку при аутентификации через CHAP мы должны высылать удалённой стороне случайный ключ и имя нашей системы, это имя необходимо задать с помощью параметра name, например, в файле /etc/ppp/options:

modem
crtscts
asyncmap 0
name fast

Если мы не укажем имя нашей системы, pppd будет использовать в этом качестве полное доменное имя компьютера, на котором его запустили, в нашем случае, dial.fast.ru. Иногда в рекомендациях по настройке pppd зачем-то используют параметр domain. Я не знаю, какая цель при этом преследуется, но этот параметр влияет только на имя нашей системы. Если мы укажем параметр domain fast.ru, то имя нашей системы станет dial.fast.ru.fast.ru. Не знаю, как Вам, но мне это совершенно не нужно. Что касается PAP, то для него имя нашей системы необязательно, но не помешает.

В принципе, для клиентов, использующих аутентификацию PAP или CHAP может вообще не быть записи в /etc/master.passwd, поскольку имена и пароли для аутентификации находятся в файлах /etc/ppp/pap-secrets и /etc/ppp/chap-secrets (для краткости мы будем называть их файлы secrets) в виде строк:

max       fast     abcdefg         *
Формат этой строки такой — имя удалённой системы "max", имя нашей системы "fast", пароль удалённой стороны "abcdefg" и разрешённые для удалённой стороны IP-адреса "*" (символ "*" означает любые). secrets-файл на удалённой стороне должен содержать похожую строку:
max       fast     abcdefg
но там поля имеют другой смысл — имя его системы — "max", имя нашей системы — "fast" и пароль — "abcdefg".

В одном и том же файле могут хранится имена и пароли как для аутентификации удалённых систем, так и для аутентификации себя. Первые визуально отличаются наличием поля IP-адреса. Кроме того, имя нашей системы при аутентификации удалённых систем можно заменить символом "*". Таким образом, наш файл secrets будет выглядеть так:

igor      cool     1234567
max       *        abcdefg         *
Первая строка — это наше имя и пароль для аутентификации у нашего провайдера Cool Connection, а вторая — это строка для аутентификации нашего дайлап-клиента "max".

В файле /etc/ppp/pap-secrets пароль клиента может хранится не открытым текстом, а в виде результата функции crypt, например, вот так:

max       *        $1$1q2w3e4r$UptrhXMwGUeq2z68qDcXi/   *
При аутентификации PAP pppd сначала пытается сравнить присланный пароль с имеющимся и, если они не совпадают, pppd пропускает его через crypt и пытается сравнить снова.

Если pppd указать параметр login, то при аутентификации PAP он будет проверять в /etc/master.passwd пароль пользователя, имя которого совпадает с именем удалённой системы. Кроме того, pppd проверит, что бы это имя не было в файле /etc/ppp/ppp.deny, а шелл этого пользователя присутствовал в файле /etc/ppp/ppp.shells. Помимо этого, проверяется срок действия аккаунта пользователя.

Файлы /etc/ppp/ppp.deny и /etc/ppp/ppp.shells и срок действия аккаунта проверяет только pppd, входящий в комплект FreeBSD. О других отличиях читайте в статье "Сравнение версии pppd, входящей в дистрибутив FreeBSD, c обычной версией"

Если все проверки пройдут удачно, pppd запишет время работы этого пользователя в файле /var/log/wtmp. При использовании параметра login пароль клиента может вообще не храниться в /etc/ppp/pap-secrets:

max       *        ""               *
Надо заметить, что хранить пароль в шифрованном виде или в виде "" можно только при аутентификации PAP. Используя CHAP, мы вынуждены хранить пароль открытым текстом.

Теперь перейдём к полю адреса. Как мы уже говорили, символ "*" в четвёртом поле файла secrets разрешает удалённой стороне использовать любой адрес, но мы также можем разрешить использование только определённых адресов, указав их через пробел:

max       *        abcdefg         192.168.1.200 192.168.1.201
То есть, в нашем случае, max, пользуясь аутентификацией через PAP или CHAP, сможет заходить только на линии ttyd1 и ttyd2.

Если число запрещённых адресов меньше, чем разрешённых, то удобнее воспользоваться символом"!":

max       *        abcdefg         * !192.168.1.202
то есть, разрешить все и запретить 192.168.1.202. В нашем случае это аналогично предыдущему варианту.

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

max       *        abcdefg         192.168.1.200/30
то есть, разрешить все адреса с 192.168.1.200 по 192.168.1.203.

Указав в поле адреса на первом месте символ"-", мы запрещаем использовать любые адреса, что выливается в невозможность аутентификации через PAP или CHAP для данного клиента:

max       *        abcdefg         -

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

Наконец, с помощью этого поля можно назначить адрес удалённой стороне:

max       *        abcdefg         :192.168.1.210
или оба адреса для данного соединения:
max       *        abcdefg         192.168.1.2:192.168.1.210
Это назначение происходит уже после того, как pppd назначил адреса в описанном нами порядке и является завершающей стадией в этой эпопее. Вместо IP-адресов можно использовать доменные имена.
Назначать адреса в secrets-файлах может только pppd, входящий в комплект FreeBSD. О других отличиях читайте в статье "Сравнение версии pppd, входящей в дистрибутив FreeBSD, c обычной версией"

Может ли pppd использовать для аутентификации одних клиентов PAP, а для других — CHAP ? В общем случае — нет. Дело в том, что о способе аутентификации pppd договаривается с удалённой стороной ещё до того, как эта удалённая сторона сообщит своё имя. В результате может возникнуть следующая ситуация. Перед тем, как определить способ аутентификации, pppd заглядывает в файл /etc/ppp/chap-secrets и, если он находит там хотя бы одну строку, у которой второе поле равно "*" или совпадает с именем нашей локальной системы, то он предлагает удалённой системе аутентификацию через CHAP. Если удалённая сторона согласится и затем с самыми хорошими намерениями передаст нам своё имя, а этого имени в файле /etc/ppp/chap-secrets не окажется, то аутентификация не удастся. Если на удалённой стороне пользуются pppd и точно знают, что аутентификация через CHAP им не светит, они могут указать ему параметр refuse-chap и удалённый pppd ответит отказом, после чего аутентификация будет проводиться через PAP. Если же на удалённой стороне используется Windows, то дело тухляк. В Windows можно отказаться от PAP, но никак не от CHAP.

Поэтому, если мы решили использовать CHAP, то всех клиентов под Windows придётся занести в файл /etc/ppp/chap-secrets. Я бы рекомендовал использовать PAP для всех клиентов, потому что в этом случае, во-первых, пароль можно хранить в зашифрованном виде или даже в /etc/master.passwd, а во-вторых, параметр login записывает время работы клиента. Что касается того, что пароль передаётся в открытом виде по каналам связи, то для телефонных линий, на мой взгляд, это не критично. Поэтому в наш файл /usr/sbin/pppd.sh можно добавить такие параметры:

#!/bin/sh

/usr/sbin/pppd auth login require-pap refuse-chap

Мы запрещаем CHAP, требуем PAP, используем для аутентификации /etc/master.passwd, и, кроме того, записываем время работы в файл /var/log/wtmp.

(C) Игорь Сысоев
http://sysoev.ru