PAP — старый, но не бесполезный!?

[INSTE]

Ростелеком в Мордовии (про другие регионы не могу сказать) для PPPoE предлагает только PAP, и похоже так будет продолжаться еще неизвестно сколько времени. Правда они что-то там мутили с qinq, привязкой mac адресов и логина/пароля от интернета к порту на свиче доступа, а также учетные данные доступа в личный кабинет отличаются от таковых для доступа в интернет, так что атаку из поста реализовать будет не так просто.

[reve1]

Вы рассматриваете проблему со стороны провайдера, а я бы расценивал ее больше со стороны клиента.

1. mac переписать не проблема, видимо речь идет о Port security и его обойти тоже не проблема;
2. QinQ далеко не панацея, тем самым они лишь сузили сектор атаки;
3. учетные данные в ЛК, я надеюсь что мой провайдер скорее исключение.

Проблема заключается в самом использовании устаревшего протокола пользователем. На вашем примере мой мозг рождает следующее — MITM-атака за 2 минуты с целью ну скажем промышленного шпионажа.

1. разрываем L2;
2. устанавливаем оборудование;
3. востанавливаем L2;
4. поднимаем PPPoE узнаем login/password;
5. авторизуем пользователя у себя и выкидываем на улицу.

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

[VBKesha]

Я не знаю внутреннего устройства этих протоколов авторизации, но разве нельзя пропатчить сервер чтобы он просто авторизовывал всех независимо от логина/пароля? Тогда для данной атаки вообще не будет разница что там пользователь выбрал в качестве авторизации.
Поверхностно глянул нужен MS-CHAPv2 с двух стронней проверкой подлинности.

[reve1]

Нет, фактически при самом становлении PPPoE или PPTP соединения идет процесс аутентификации.
Скажем для PPPoE описанный еще в 1994г в RFC 1661 (3.2 по диаграмме все будет ясно). Самый слабым при этом — PAP.

[il--ya]

Авторизовывать можно, но пароль вы так просто не узнаете, поскольку он шифруется. Известны методы взлома, chap и ms-chapv2, но они требуют некоторых усилий.

[INSTE]

MITM разумеется никто не отменял, каждый раз проходя в подъезде мимо своего кабеля ethernet, висящего голым до распаечной коробки становится как-то стремновато :)

[INSTE]

Кстати я даже не знаю что страшнее в случае с MITM — потерять учетные данные доступа к инету, или же сам интернет-трафик. Потому что даже в случае SuperCHAPv100500 клиент будет авторизован, и весь его трафик можно спокойно слушать в пассивном режиме — достаточно взять 2 сетевухи, поставить linux, добавить их обе в bridge (его надо поднять, но без адреса и запретить ARP) — и никто не заметит этот пассивный сниффер.

[CMHungry]

«вешаем на wan IP-адрес шлюза провайдера» — вот тут на свитчах должны были ACL сработать у хорошего провайдера.

[reve1]

Не встречал провайдеров с L3 коммутаторами доступа!
Стандартные решения L2+ не позволят войти на сам коммутатор, но явно ACL помешать присвоить чужой IP им не под силу.

Конечно у провайдера есть механизмы по борьбе с этой болячкой. IP Source Guard + DHCP snooping +… + но на практике все не так просто.

[xBrowser]

Скорее всего CMHungry имел ввиду сброс пакетов на установку соединения, которые могут исходить только от сервера на юзерских портах. Легко реализуется по паттернам, например, на самом используемым в былые времена, да и сейчас не утратившем актуальности Dlink DES-3526 (L2). Аналогично в дроп можно отправлять все пакеты, которые исходят не от выданного абоненту IP-адреса.

[reve1]

Ну скажем при PPPoE нам менять IP адрес и вовсе не нужно, нас найдет дисковери.
Я согласен с вами, да и писал это ранее, у провайдера есть инструменты для минимизации вероятных атак, это проблема клиента.
Но суть не в том. Сам факт использования PAP это дырка величиной в 20 лет.

[CMHungry]

pppoe-ответка режется с юзерских портов. Если уж очень надо рррое. Хотя у большинства уже давно ipoe.

[CMHungry]

всё проще, чем многие себе думают =) а вообще PCF есть во многих длинках, 3528-3028-3200. Да и просто повесить привязку ип-порт умеют почти все модели коммутаторов доступа. Ну или строить дерево private vlan

[Shvedov]

В названии 2+ уже много скрыто… Те же длинки, 3526, 3200 умеют достаточно.
Режем PPPoE Offer'ы, DHCP сервера, ARP ответы и так далее…
Провайдеру стоило побеспокоиться об абонентах и соблюдении 152 ФЗ.

[RicoX]

Расскажу немного со стороны провайдера почему так. Отключить одномоментно PAP на всех брасах, если мы говорим о PPPoE — дело пары команд и можно оставить только шифрованные подключения, но представим сеть средних размеров тысяч 40 абонентов, она такой появилась не сразу, а развивалась скажем лет 10, так вот если отключить PAP то отвалится и не сможет подключиться процентов 15-20 от всей сети (древние роутеры которые по дефолту лезут только по PAP и их надо перенастраивать) или более 5000 абонентов, втечение ближайших дней все эти заявки упадут на службу технической поддержки, вот кому оно нужно? Итого почти все провайдеры поддерживают одновременно кучу вариантов и PAP и CHAP и MS-CHAP(1/2) и даже экзотику типа EAP-TLS (и такое встречал) или там MD5, чаще всего абоненты, которые что-то понимают и кому не пофигу просто ставят себе нужный протокол в настройках подключения и спят спокойно, но заставить проделать то-же самое тысячи домохозяек провайдеру не выгодно как с репутационной стороны, так и в плане издержек. Хотя многие провайдеры уже переходят ударными темпами на IPoE в том или ином виде и там проблемы PAP уже нет.

[Shvedov]

Оставили только chap уже давно. Никаких проблем не вызывает, техподдержка не теребит инженеров.

[RicoX]

Вопрос объемов сети, мы для теста выключали 1 BRAS на одном районе около 3000 пользователей онлайн, зафиксировали более 300 заявок в первые сутки и вернули обратно как было. Технически оставить только chap не сложно, но вот операционные расходы не окупятся.

[reve1]

Аналитика от бога. Сначала сообщаем что все бред, после рассказываем «свой» бред.
Особенно порадовала проблема с левыми DHCP при включенном QinQ (поскольку иначе на дом vlan не напастись), вот это квалификация! Мы включили QinQ но забыли про DHCP snooping. Брава коллега, снимаю шляпу.
Повторюсь еще раз статья не о том какие плохие провайдеры. Статья о 87% которые ни сном не духом и о том что дырка 20 лет как стоит по умолчанию.

Спасибо.