Авторизация и PPP
С PPP каждая система может требовать, чтобы другой конец линии опознал себя, используя один из двух опознавательных протоколов. Это Password Authentication Protocol (PAP) и Challenge Handshake Authentication Protocol (CHAP). Когда связь установлена, каждый может запросить другой конец линии, чтобы опознать себя, независимо от того, является ли он вызывающим или вызываемым. Ниже я буду говорить о «клиенте» и «сервере», когда захочу сделать различие между системой опознания и аутенфикатором. PPP daemon может спрашивать о подлинности, посылая LCP-запрос конфигурации, опознающий желаемый протокол.
PAP против CHAP
PAP в основном работает как нормальная процедура входа в систему. Клиент опознает себя, посылая имя пользователя и пароль серверу, который сравнивает их с базой данных. Этот метод легко уязвим для посторонних наблюдателей, которые могут попытаться получить пароль, слушая последовательную линию.
CHAP не имеет этих недостатков. С CHAP аутенфикатор (сервер) посылает беспорядочно сгенерированную «challenge»-строку клиенту, наряду с именем хоста. Клиент использует имя хоста (hostname) для того, чтобы искать соответствующий шифр, объединяет его с challenge и шифрует строку, используя однонаправленную hash-функцию. Результат будет возвращен на сервер наряду с hostname клиента. Сервер теперь выполняет те же самые вычисления и опознает клиента.
Другая особенность CHAP то, что он не требует опознания клиента для опознания самого себя при запуске, но посылает challenge в определенные промежутки времени, чтобы удостовериться, не был ли клиент заменен злоумышленником, например, переключив телефонные линии.
Пакет pppd хранит секретные ключи для CHAP и PAP в двух отдельных файлах, называемых соответственно /etc/ppp/pap-secrets и /etc/ppp/chap-secrets . Записывая удаленный хост в один или другой файл, Вы имеете хороший контроль над CHAP или PAP.
По умолчанию pppd не требует установления подлинности удаленной машины, но соглашается опознавать себя, когда она запросит опознание. Так как CHAP намного более совершенен, чем PAP, pppd пробует использовать его всякий раз, когда это возможно. Если удаленная машина этого не поддерживает, или если pppd не может найти CHAP-шифр для удаленной системы в файле chap-secrets , он возвращается к PAP. Если он не имеет также и PAP-шифра, то связь закроется.
Это поведение может быть изменено. Например, когда дается ключевое слово auth , pppd требует, чтобы другой конец линии опознал сам себя. pppd согласится использовать CHAP или PAP для этого, как только будет имеет соответствующий шифр в базе данных CHAP или PAP соответственно. Имеются другие опции, чтобы включить или выключить частный опознавательный протокол, но я не буду описывать их здесь.
Если все системы, с которыми Вы работаете по PPP соглашаются опознавать самих себя, Вы должны поместить опцию auth в глобальный файл /etc/ppp/options и определить пароли для каждой системы в файле chap-secrets . Если система не поддерживает CHAP, добавьте запись к файлу pap-secrets . Таким образом, Вы можете удостовериться в том, что никакая неопознанная система не соединяется с Вашим хостом.
Следующие два раздела обсуждают два PPP файла шифров: pap-secrets и chap-secrets . Они размещены в /etc/ppp и содержат тройки клиентов, серверов и паролей, необязательно сопровождаемых списком адресов IP. Интерпретация клиента и сервера отлична для CHAP и PAP.
Файл для CHAP
Когда надо опознать себя с некоторым сервером, используя CHAP, pppd ищет в файле chap-secrets запись с именем клиента, равным локальному hostname, и именем сервера, равного удаленному hostname, посланному в CHAP Challenge. При требовании опознавания себя роли просто поменялись: pppd будет искать запись с именем клиента, приравненным к удаленному hostname (посланному в CHAP-ответе клиенту) и имя сервера, приравненное локальному хосту.
Типовой файл chap-secrets для vlager :
При установлении PPP-связи с c3po , c3po просит vlager опознать себя, используя CHAP и посылая CHAP challenge. Затем pppd просматривает файл chap-secrets для записи с клиентской областью, приравненой к vlager.vbrew.com и областью сервера, приравненной к c3po.lucas.com , и находит первую строку, показанную выше. Затем производится CHAP-ответ из challenge string и шифра ( Use The Source Luke ) на машину c3po .
В то же самое время pppd составляет CHAP challenge для c3po , содержащую уникальную challenge string, и полностью квалифицированное доменное имя vlager.vbrew.com . В ответ c3po создает CHAP-ответ способом, который мы только что обсудили, и возвращает его vlager . Теперь pppd извлекает клиентский hostname ( c3po.vbrew.com ) из ответа и ищет в файле chap-secrets строку, соответствующую c3po как клиенту и vlager как серверу. Вторая строка задает pppd объединить CHAP challenge с паролем ( arttoo! arttoo! ), зашифровать результат и сравнить CHAР-ответом c3po .
Произвольное четвертое поле перечисляет адреса IP, которые допустимы для клиентов в первом поле. Адреса могут быть заданы в dotted quad notation или как имена машин, которые будут найдены через сервер имен. Например, если c3po запросил во время IPCP-переговоров использование IP-адреса, который не в этом списке, запрос будет отклонен, и IPCP будет выключено. В типовом файле, показанном выше, c3po будет ограничен использованием собственного адреса. Если поле адреса пусто, будут позволяться любые адреса. Задание тире ( — ) запрещает использование IP-адреса.
Третья строка в примере файла chap-secrets позволяет любому хосту установить связь PPP с vlager потому, что * в поле клиента или сервера соответствует любому hostname. Единственое требование: он знает пароль и использует адрес pub.vbrew.com . Запись с групповым символом для имен машин может появится где угодно в файле шифров, так как pppd будет всегда использовать наиболее подходящую запись, которая применима к паре сервер/клиент.
Это добавит имя домена Brewery к vlager для всех действий по авторизации. Для локального имени интересны также опции usehostname и name . Когда Вы задаете локальный IP-адрес в командной строке, используя local : remote и имя local вместо IP-адреса, pppd использует его как локальный hostname.
Файл для PAP
Файл шифров PAP очень похож на тот, который используется CHAP. Первые два поля всегда содержат имена пользователя и сервера, третье поле хранит шифр PAP. Когда удаленная машина посылает запрос опознания, pppd использует запись, которая имеет поле сервера равное локальному hostname, и поле пользователя, равное имени пользователя, посланному в запросе. Когда опознание произойдет, pppd выберет шифр, который будет послан с полем пользователя, приравненным к локальному имени пользователя, и полем сервера, приравненным к удаленному hostname.
Первая строка используется для того, чтобы опознать нас, когда мы соединяемся с c3po . Вторая описывает, как пользователь c3po должен опознавать себя при соединении с нами.
Имя vlager-pap в столбце имени пользователя мы посылаем на c3po . По умолчанию pppd выберет локальный hostname как имя пользователя, но Вы можете также определить различные имена, давая опцию user , сопровождаемую эти именем.
В четвертом поле (и всех следующих) Вы можете определить, какие адреса IP разрешены точно, как в файле шифров CHAP. Удаленная машина затем может запроситьь только адреса из этого списка. В типовом файле мы требуем, чтобы c3po использовал реальный адрес IP.
Заметьте, что PAP довольно слабый опознавательный метод, и лучше использовать CHAP, если это возможно. Я не буду здесь описывать PAP в деталях: если Вы заинтересованы в использовании PAP, то найдете больше сведений на pppd(8) man-странице.
Источник
В чём разница между PAP и CHAP
PAP и CHAP – протоколы аутентификации, использующиеся в протоколе PPP. PAP расшифровывается банально – Password Authentication Protocol. Возможно такая простая расшифровка связана с тем, что протокол был одним из первых. CHAP расшифровывается как Challenge Handshake Authentication Protocol. В курсе CCNA затрагиваются оба этих протокола.
Как работает PAP?
Клиент хочет подключиться к серверу, он отправляет серверу пароль, сервер отвечает либо «Да», либо «Нет». Казалось бы, всё просто – зачем добавлять что-то ещё? Однако, всё становится сложнее, в случае если мы в силу каких-то обстоятельств обратились не к серверу, к, которому собирались, а к устройству злоумышленника. В этом случае получается, что спрашивая его, нравится ли ему наш пароль, мы по сути просто передаём ему пароль, с которым он в дальнейшем может делать всё что угодно. Чтобы избежать такой ситуации был придуман CHAP.
Как работает CHAP?
Клиент хочет обратиться к серверу, сервер передаёт клиенту случайную строку, клиент берёт пароль и эту строку и вычисляет от неё MD5 хеш, который возвращает серверу. Сервер проделывает те же операции (если он сам, конечно, знает правильный пароль). Если хеши слвпадают – клиент авторизован. Что мы получаем? Если клиент не знает пароль – хеши не совпадут, если вместо сервера злоумышленник – он получит только хеш, из которого ничего не выудить.
Таким образом, в реальных ситуациях лучше использовать протокол CHAP.
Источник
Linux.yaroslavl.ru
Модная аутентификация — PAP и CHAP
До сих пор наш скрипт сам выполнял аутентификацию, то есть, вводил имя и пароль в ответ на запросы удалённой стороны. Но PPP предусматривает и свои способы аутентификации — PAP (Password Authentication Protocol) и CHAP (Challenge Handshake Authentication Protocol) и мы можем ими воспользоваться, если удалённая сторона достаточна сообразительна, чтобы не только выдать «login:«, но и провести PAP или CHAP аутентификацию.
Нужно заметить, что комбинация FreeBSD + getty до недавнего времения не была таким сообразительным прибором, но, начиная с getty распознает начальные LCP-кадры PPP-соединения и может вызывать, скажем, pppd, который и решает, что делать дальше. До этого getty умел только выдать этот самый «login:» и приходилось использовать mgetty.
Так как наш скрипт дозвонки больше не будет заниматся аутентификацией, нужно убрать из него имя пользователя «igor«, его пароль «1234567» и ошибку аутентификации
Теперь скрипт заканчивает работу сразу же, как получит строку «login:«. Отметим, что приглашние «login:» не имеет ни какого отношения к PAP и CHAP, и pppd воспринимает его не более как шум в линии, поэтому вместо этой строки может быть любое другое приглашение провайдера, в крайнем случае, «>«.
PAP аутентификация происходит следующим образом — при установлении PPP-соединения удалённая сторона предлагает нам аутентификацию PAP. Мы соглашаемся и затем передаем наше имя и пароль открытом текстом. Если удалённую сторону имя и пароль устраивает, то аутентификация считается успешной. Имена и пароли для PAP хранятся в файле /etc/ppp/pap-secrets. У него должны быть такие правами доступа Для нашего случая мы запишем в этот файл:
Формат этой строки таков — наше имя, имя удалённой стороны и пароль. В PAP используется только наше имя и пароль, а имя удалённой стороны «cool» может быть произвольным. В принципе, оно нужно только для того, что бы pppd мог определить, какой пароль нужно использовать в случае, когда Вы используете одно и тоже имя у разных провайдеров, например:
Теперь мы можем звонить провайдеру:
Параметры user igor и remotename cool позволяют однозначно определить, какой пароль использовать при аутентификации, в данном случае это «1234567«. Как уже говорилось, параметр remotename необходим только, если мы не можем однозначно выбрать пароль из файла /etc/ppp/pap-secrets. Имя нашей стороны можно также задать с помощью параметра name igor, но параметр user имеет больший приоритет. Заметим, что хотя пароль передается в открытом виде, удалённая сторона может хранить пароль в виде результата какой-либо хэш-функции, например, MD5, в качестве параметра которой, выступает пароль.
CHAP аутентификация происходит следующим образом — при установлении PPP-соединения удалённая сторона предлагает нам аутентификацию CHAP. Мы соглашаемся, и удалённая сторона высылает нам ключ (challenge), состоящий из случайной последовательности символов, и своё имя. Мы берем наш пароль и присланный ключ и прогоняем их через алгоритм MD5. Получившийся результат высылаем вместе со своим именем. Удалённая сторона, зная наш пароль и высланный её ключ, в свою очередь, проделывает тоже самое у себя, и если её результат совпадает с присланным нами, то аутентификация считается успешной. Таким образом, пароль не передается в открытом виде, но удалённая сторона должна хранить наш пароль в открытом виде.
Имена и пароли для CHAP хранятся в файле /etc/ppp/chap-secrets, права доступа у него должны быть такие же, как для PAP: и формат строк тоже совпадает:
Теперь наша строка для звонка провайдеру выглядит так:
Обратите внимание, что она отличается от PAP только отсутствием параметра remotename. Это объяснятеся тем, что удалённая сторона сама говорит своё имя, поэтому её имя, записаное в файле /etc/ppp/chap-secrets, не может быть произвольным, как это было в случае с PAP. Даже если Вы зададите параметр remotename, имя, сообщённое удалённой стороной, имеет больший приоритет. Что касается имени нашей стороны, то оно может быть также задано с помощью параметра
Может ли pppd аутентифицировать себя в одних случаях через PAP, а в других — через CHAP ? Ответ — да. При запуске pppd проверяет, как он может аутентифицировать себя, исходя из локального имени и имени удалённой стороны, то есть, есть ли в файлах /etc/ppp/pap-secrets или /etc/ppp/chap-secrets строки с такими именами. И если, скажем, удалённая сторона предлагает CHAP, а pppd не находит пароль в файле /etc/ppp/chap-secrets, то он запросит PAP и если это устраивает удалённую сторону, то аутентификация пройдет по PAP.
Кроме того, можно указать pppd, чтобы он не соглашался проводить аутентификацию тем или иным способом или же требовал какого-то одного способа с помощью различных комбинаций параметров refuse-pap, refuse-chap, require-pap и require-chap. Раньше эти параметры назывались соответственно -pap, -chap, +pap и +chap.
Источник
PAP — старый, но не бесполезный!?
Как давно интернет провайдеры похоронили PAP? 5, 10, 15 лет назад?
Однако Password Authentication Protocol живее всех живых. Описания и схему выполнения подключения можно найти здесь. Если заглянуть в только вышедшую Windows 10 и попробовать создать там PPPoE подключение, по умолчанию увидим мы там следующую картину:
А ведь выбор протокола аутентификации зависит не от клиента, вам лишь предлагают, соглашаться или нет — решать вам.
Редко в каких инструкциях от провайдера кроме всего прочего идет графа «Безопасность», это если касаться Windows подключений, про всеми любимые Wi-Fi роутеры можно и вовсе забыть.
А между тем на дворе 2015 год. В магазинах продаются девайсы, ценник которых, не превышая 30$, позволяет даже непосвященному стать небольшим городским провайдером.
Шла суббота
Тихий субботний вечер, на экране любимый сериал. Закончилась одна серия и я сидел с предвкушением ожидая последующей, после 5 минут изучения темного экрана своего телевизора я сообразил что — «Кина небудет, интернет закончился».
Rb750 сообщил что PPTP соединение disconnected. Посмотрев количество mac-адресов (47 против обычных 200+) в бридже на котором висит wan интерфейс справедливо сделал вердикт что на трассе до меня у провайдера проблемы с L1, а значит скорой помощи можно не ждать.
У моего городского провайдера весьма интересный способ раздачи логинов: транслит от улицадом-квартира, так например абонент проживающий на улице 40 лет Октября 14 кв 17 получил бы логин 40let14-17. Возникло желание узнать кто страдает вместе со мной?
Поднимаем PPTP сервер на rb750, вешаем на wan IP-адрес шлюза провайдера. Включаем debug,pptp и соседи с надеждой начинают подключатся к нам.
Ох, да сколько же вас! Сначала дружными рядами отстучались разномастные Wi-Fi (TP-LINK, D-Link, Asus и ко) чуть позже в логах я увидел и host-name=HOME-PC.
Однако никому из них подключиться не удалось, что естественно ведь в secrets их имен быть не могло, а уж тем более и паролей.
А что если убрать в настройках PPTP сервера аутентификацию с использованием chap/mschap/mschap2 и оставить только PAP?
Результаты шокировали:
- из 47 хостов авторизации запросили 43.
- из 43 предложений авторизоватся по PAP отказом ответили — 2.
- 41 хост или 87,2% добровольно отдали мне свой логин-пароль.
Раньше было лучше?
Мы живем в мире услуг и сервиса. Нам уже давно мало самого факта подключения к всемирной паутине, мы ходим делать это из ванны, оплачивать на кухне, хотим чтобы нам приходила СМС о низком балансе на нашем счету, хотим добровольной блокировки когда едем на море.
Конкуренция вынуждает провайдеров накручивать плюшки в личном кабинете. Мой не исключение.
Получив уже известные результаты я 2й раз за 6 лет с момента заключения договора с моим провайдером зашел в личный кабинет. Желания вредить соседям нет, обогащаться за их счет также, поэтому я использовал личные логин/пароль чтобы узнать что мой провайдер может мне предложить:
- лицевой счет;
- паспортные данные;
- номер моб. телефона;
- баланс;
- кредит;
- блокировка;
- перевод;
- отчет по трафику;
- изменение тарифного плана.
По моему этих аргументов для 87% должно быть вполне достаточно чтобы заняться своим подключением и хотя бы выключить PAP?
Источник
