Серьезным преимуществом РРР перед SLIP являются более надежные механизмы обеспечения безопасности. Чтобы повысить безопасность, добавьте следующие параметры pppd в файл /etc/ррр/options:
lock auth usehostname domain wrotethebook.com
Первый параметр, lock, предписывает pppd использовать файлы блокировки в стиле UUCP. Это предотвращает вмешательство в РРР-соединения со стороны других приложений, таких как UUCP или эмулятор терминала. Параметр auth требует авторизации второй стороны для создания канала РРР. Следуя этому указанию, локальная система запрашивает данные аутентификации у второй стороны. Вторая сторона при этом может и не запрашивать аналогичные данные у локальной системы. Если администратор удаленной системы требует аутентификации вашей системы, он должен использовать ключевое слово auth в настройках своей системы. Параметр usehostname предписывает использовать имя узла в процессе аутентификации и запрещает пользователю устанавливать произвольное имя локальной системы при помощи параметра name. (Очень скоро мы еще вернемся к вопросу проверки подлинности.) Последний параметр дополняет используемое в процессе проверки подлинности локальное имя до абсолютного - указанием доменного имени.
Вспомните, что параметры файла -/.ррргс и параметры командной строки pppd имеют приоритет более высокий, чем те, что содержатся в файле /etc/ ррр/options. Такая ситуация может отрицательно повлиять на безопасность. По этой причине некоторые параметры - включая только что перечисленные, будучи определенными в файле /etc/ррр/options, уже не могут быть изменены.
pppd поддерживает два протокола проверки подлинности: протокол аутентификации с предварительным согласованием вызова CHAP (Challenge Handshake Authentication Protocol) и протокол аутентификации пароля PAP (Password Authentication Protocol). PAP - это простая система парольной безопасности, уязвимая для всех видов атак на пароли многократного применения, тогда как CHAP предоставляет более совершенные механизмы проверки подлинности, не требующие использования паролей многократного применения и периодически выполняющие аутентификацию удаленной системы.
В процессе проверки подлинности используются два файла: /etc/ррр/chapsecrets и /etc/ррр/рар-secrets. Приведенные выше параметры предписывают pppd прежде всего попытаться аутентифицировать удаленную систему посредством CHAP. Такая проверка требует присутствия определенной информации в файле chap-secrets, и удаленная система должна ответить на вызов CHAP. Если не выполнено хотя бы одно из условий, pppd пытается идентифицировать удаленную систему посредством РАР. Если отсутствует подходящая запись в файле pap-secrets, либо удаленная система не ответила на вызов РАР, попытка установить соединение РРР заканчивается неудачей. Такой механизм позволяет выполнять проверку подлинности удаленных систем посредством CHAP (предпочтительного протокола), если возможно, или использовать РАР в качестве запасного варианта для систем, поддерживающих только РАР. Однако чтобы этот механизм заработал, необходимо поместить корректные записи в оба файла.
Каждая запись файла chap-secrets содержит до четырех полей:
клиент - Имя компьютера, который должен ответить на вызов, то есть компьютера, для которого необходимо произвести аутентификацию перед созданием соединения. Речь не обязательно идет о клиенте, обращающемся к серверу РРР: в большинстве документов используется термин клиент, хотя на деле это просто система-респондент - та, которая отвечает на вызов. Обе стороны канала РРР могут принудительно проходить проверку подлинности. В вашем файле chap-secrets, вероятно, будет по две записи на каждую удаленную систему: одна запись для аутентификации этой системы, и еще одна, позволяющая проходить идентификацию по требованию этой системы.
сервер - Имя системы, от которой исходит вызов CHAP, то есть компьютера, который требует аутентификации второй стороны перед созданием соединения РРР. Речь не обязательно идет о сервере РРР. Система-клиент вполне может потребовать предоставления данных идентификации у сервера. Термин сервер используется в большинстве документов, хотя на деле это система, проверяющая допустимость ответа.
секрет - Секретный ключ, которым шифруется строка вызова при передаче системе, от которой исходил вызов. адрес - Адрес, представленный именем узла или IP-адресом, приемлемый для узла, указанного в первом поле. Если узел-клиент попытается воспользоваться другим адресом, соединение будет разорвано, даже если клиент правильно зашифровал ответ на вызов. Данное поле является необязательным.
Файл chap-secrets узла ring может иметь следующий вид:
limulus ring Peopledon'tknowyou 172.16.15.3 ring limulus andtrustisajoke. 172.16.15.1
Первая запись используется для проверки узла limulus удаленного сервера РРР. Проверяется подлинность узла limulus, проверка выполняется системой ring. Секретный ключ представлен строкой «Peopledon'tknowyou». Допустимый адрес - 172.16.15.3, то есть адрес, назначенный системе limulus в таблице узлов. Вторая запись позволяет проверить узел ring, когда вызов исходит от системы limulus. Секретный ключ - «andtrustisajoke.». Узлу ring разрешено использовать только адрес 172.16.15.1. Пара записей, по одной на каждую сторону канала, - нормальное явление. Файл chap-secret обычно содержит две записи на каждый канал РРР: одну для проверки подлинности удаленной системы, и вторую - для ответов на вызовы, исходящие от удаленной системы.
Используйте РАР только по необходимости. Если речь идет о системе, не поддерживающей CHAP, создайте для этой системы запись в файле pap-secrets. Формат записей файла pap-secrets точно такой же, как формат записей chap-secrets. Система, не работающая с CHAP, может хранить следующие записи в файле pap-secrets:
24seven ring Wherearethestrong? 24seven.wrotethebook.com ring 24seven Whoarethetrusted? ring.wrotethebook.com
Здесь снова пара записей: одна для удаленной и одна для локальной системы. Мы поддерживаем CHAP, а удаленная система - нет. Таким образом, мы должны иметь возможность ответить по протоколу РАР, если вторая сторона запросит данные идентификации.
Аутентификация РРР повышает уровень безопасности при работе по коммутируемым соединениям. Наибольшую актуальность она приобретает для серверов РРР, обслуживающих удаленные системы. В следующем разделе мы рассмотрим настройку сервера РРР.