Как стать автором
Обновить

Комментарии 63

Как вы узнали IP-адрес шлюза провайдера?
По tcpdump-у?
Всё верно, второй адрес в ppp подключение который и является роутом не передается в каждом пакете, там только мак pppoe сервера. Можно либо стимулировать клиента повторно авторизоваться с сервером, (например временно разорвав подключение) тогда этот адрес будет передан в IPCP-пакете, либо спросить у провайдера.
Он обычно не меняется. Можно просто узнать из легитимной сессии.
PPPoE не предназначен для использования в средах, где возможна такая врезка (читай: для FTTx). Отсюда и фигня.
В домовых сетях рулит и педалит DHCP + Option 82 и, соответственно, авторизация по порту коммутатора.
Билайн как использовал PPTP, так и использовал.
Билайн — мудаки.
это корбиновское наследие, жаль, что избавляться от него не спешат.
*YES*
а как с таким перехватом дела на adsl линиях?
Будет посложнее, чем подклюение к своему ethernet'у, но принцип тот же.
У жертвы отключится не только интернет, но и телефон, т.е. он быстрее почувствует неладное :)
Не почувствует, всего лишь один глюк в линии в момент врезки.
Если исходного клиента не отрезать, то интернет во врезке скорее всего вообще работать не будет.
Если исходного клиента не отрезать, то интернет во врезке скорее всего вообще работать не будет.
Когда вы последний раз домашним телефоном пользовались;)?
Полчаса назад, а что?
Комментарий из прошлого века?
В телефонном общении обычно две стороны разговора, среднее арифметическое их привычек попадает в прошлый век, да. Хотя телефон — это вообще позапрошлый :)
Говорят, можно в разрез воткнуть DSLAM с зеркалированием порта.
DSLAM — штука не из дешёвых, хотя уже и продаётся в интернет-магазинах рядом с ковриками для мышей и стиральными машинами. А зеркалирование порта — это стандартная фича как-раз для lawful interception.
А в нашем городе в домовых сетях Билайн использует L2TP, а не PPTP. Хотя тоже без шифрования. PPTP и PPPoE — разные вещи, хотя отличия только в «конвертах».

Вроде бы L2TP и PPTP тоже можно перехватить (точнее, не перехватить, а «увести» к себе) тем же способом, т.к. авторизация (внутри PPP поверх L2TP) используется только в самом начале сессии, а в последующих пакетах идет только номер сессии.
Что-то не связывается:
dhcp — чтобы выдать адрес
option 82 — чтобы узнать с какого порта, какого коммутатора пришел dhcp запрос
авторизация по порту — разрешать инет или нет в зависимости от того, откуда пришел запрос

Каким образом это всё поможет от врезки в кабель до порта коммутатора? Через крокодильчики узнать MAC и всё остальное. Потом настроить сетевуху, обрезать, обжать подключиться вместо него и всё.

По-моему, даже легче чем с PPPoE. Что-то упустил?
Я-то думал, вы действительно PPPoE сломали, а тут незашифрованная сессия…
Он сломал то, что используется на практике у крупнейших провайдеров.
Я же не сказал, что автор что-то сделал не так. Все это, конечно, круто с точки зрения практического использования, но совсем не так интересно как могло бы быть.
Простите за ламерский вопрос.
А что если кто-нибудь из пользователей провайдера поставит свой PPPoE-сервер, не получится ли ему подключить клиентов к себе? Такое возможно, кто знает? Или все/не все провайдеры блокируют такие вещи на коммутаторах?
CHAP авторизация работает таким образом, что если обе стороны не знают комбинации логина-пароля подключится не удастся.
На своём PPoE сервере злоумышленник может просить именно PAP и если в клиенте не стоит «подключатьс только по CHAP» то вполне удастся узнать пароль. Другое дело, то можно наверное на свиах фильтровать это каким-т ообразом?
Да, CHAP-пароль вынюхать не получится, но Nastradamus спрашивал не об этом, а о «подключении клиентов к себе» — для этого пароль клиента знать не нужно, можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера». И дальше хакер может вынюхивать пароли пользователя на почту, веб-службы и т.д., если пользователь работает с ними без SSL/TLS. Поэтому если провайдер не блокирует бродкасты, то конечно подвергает своих клиентов риску.
Вы правы, я заблуждался. Мне всегда казалось что CHAP авторизация двухсторонняя.
можно ещё явно AC name указать в подключении. Если провайдер предоставляет данную информацию.
AC name можно и из записи сессии выяснить, если провайдер его не сообщает. Но к сожалению ничто не помешает злоумышленнику указать то же самое имя концентратора, там ведь никакими ЦП идентификация не защищается.
можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера».


Через этого «другого провайдера» клиент будет работать до первого обращения в техподдержку. При обращении же выяснится что клиент работает, а на BRAS-е сессии нет. Потом путём несложных манипуляций выясняется, «откуда кака прилетает» — т.е. откуда клиент получает PADO, и принимаются соответствующие меры.

Хотя практика показала, что «самозванными провайдерами» зачастую становятся не по злому умыслу, а по неумению — настраивают, к примеру, VPN на кошке, и выставляют наружу PPPoE вместо L2TP. И потом еще удивляются, за что им порт уложили.
Это понятно, что вскрыть размножение провайдеров легко. Хотя бы по самому факту бродкастов.

menraen: практика показала, что «самозванными провайдерами» зачастую становятся

Даже как-то не по себе стало от прочтения такой «частой практики». Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты, и не мониторит, и что факты таких приключений выясняются только при обращении клиента в техподдержку? Значит описанное в моем комменте ниже может случиться не только «теоретически»? Ой.
Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты


Какие броадкасты? PADO — вполне себе юникаст.
PADI бродкаст — его и надо блокировать (не пускать на порты других клиентов), тогда «альтернативные провайдеры» не смогут выслать в ответ PADO, и подмена сервера не состоится.

В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.

Не совсем та-же. Блокировка DHCP-сервера представляет собой drop-анье offer-ов с untrusted портов, и относится производителями оборудования к L3-функционалу. Там же, где «последняя миля» терминируется на L2-устройстве, _обычно_ есть возможность лишь запретить _любое_ общение (мультикаст, броадкаст, юникаст) кроме как с аплинком (т.н. port isolation), что и делается на практике, и лишь изредка можно ставить фильтры по Ethertype, и то — настройка таких фильтров обычно выглядит как переключатель «allow all <-> PPPoE only».
Да, уровень другой, но принцип тот же…

Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны (не в смысле уязвимостей ОС, а в смысле уязвимостей сетевой инфраструктуры). Эдакая «ЛС без сисадмина»…

Значит наличие в сети соседских бродкастов означает, что port isolation отключен, и вообще ничего не фильтруется?
Да, уровень другой, но принцип тот же…

Ваши бы слова, да производителям DSLAM-ов в уши…
Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны

Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах». Кроме того нужно понимать, что собственный провайдер — худшая из возможных целей для взлома по целому ряду причин (хотя это отнюдь не означает что провайдер не принимает мер для предотвращения взломов и других деструктивных действий).
Значит наличие в сети соседских бродкастов означает, что port isolation отключен

А где я сказал про _соседские_ броадкасты? ;)
> Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах».

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

> А где я сказал про _соседские_ броадкасты? ;)

Это я говорил ранее — в комментариях ниже про шумящие бродкастами TV-приставки Билайна.

> собственный провайдер — худшая из возможных целей для взлома по целому ряду причин

Это понятно, я о том же и говорил, что легко детектируется. Но хотелось, бы, чтобы была техническая невозможность реализации указанных атак. Т.е. фильтрация «системных» бродкастов хотя бы. А если всё так, как вы пишете, то это довольно печально. Себя-то провайдер защитит, а вот соседей друг от друга — нет.
Разумный провайдер всегда будет принимать разумные меры для защиты как себя, так и своих абонентов. Однако любой провайдер — в первую очередь коммерческая организация, и он при всём желании не может ставить 100% безопасность каждого конкретного клиента за основную цель. Осноная цель любого бизнеса — извлечение прибыли, и глупо ждать что при абонплате в среднем 5-10$ в месяц вы получите от провайдера state-of-the-art защиту от любых угроз, будете включены в «супер-умное» оборудование, умеющее «заглядывать» в заголовки до L7 включительно, и т.д. Кроме того, как опять-же показывает практика, безопасность — не та штука, которой «много не бывает», и собственные «благодарные» клиенты первыми побегут от «безопасного» провайдера к «опасному», но на котором «осёл» (к примеру) не ловит постоянно LowID.

Если же возвращаться к сабжу — да, такая атака принципиально возможна при совпадении ряда факторов, проверить совпадение которых не удастся до фактического совершения атаки — т.е. «или пан, или бан». Однако вероятность успешно, и главное — незаметно её провести ничтожно мала.

Ждать принятия провайдерами каких-либо дополнительных мер для предотвращения этого типа атак также, думаю, не стоит по уже упомянутым здесь причинам. Только если производители оборудования «почешутся». А они не почешутся, потому что от них в последнее время только и слышно что «PPPoE is dead, baby».
А что они (производители) рекомендуют на замену PPPoE?
DHCP
Ну IP-то DHCP выдаст, а дальше? Смысл всех этих VPNов и прочих виртуальных каналов в том, чтобы клиент вводил «пароль для интернета», а локальный трафик чтобы шел отдельно. Если от такой схемы отказываться, то провайдерам придётся менять все учетные схемы и тарифные планы, так?
чтобы клиент вводил «пароль для интернета» актуально для провайдеров, выросших из домосетей. PPPoE — это обычно xDSL, т.е. не домосети, а крупные телекомы, которые никогда «домосетями» не были, и под «локальным» трафиком подразумевают ни разу не трафик «внутри свича», а, к примеру, собственные сервера с контентом. Но мы уже очень сильно отклонились от сабжа топика.
Провайдеров с PPPoE в нашем регионе нет вообще, самопальные домовые сети раздают IP по DHCP, статистику считают по IP на шлюзах, старейшие «автохтонные» провайдеры региона (не домовые сети, а «наследники» телефонных пулов, сейчас у них у всех оптоволокно до большинства многоэтажек в городе, т.е. в каждом доме 4-5 провайдеров на выбор) раздают интернет по PPTP, единственный «телеком» на домашнем рынке — Билайн, у него L2TP. При этом у Билайна локальным считается весь внутригородской трафик по билайновской сети (включая трафик между клиентами — торренты и DC в основном) и до пары московских («личный кабинет»), а остальные билайновские сайты маршрутизируются по не-локальным IP, и в статистике считаются как внешние. Пиринга с местными провайдерами у билайна нет, к ним все идет через Питер+Москву. Ну то есть, у нас получается все наоборот, в сравнении с вашей картиной.
А, понял, это ответ на моё " Хотя бы по самому факту бродкастов."? Да, там неправильно, атакующий «альтернативный провайдер» может обойтись без бродкастов, если бродкасты от клиентов не блокируются.
CHAP-авторизация работает таким образом, что клиенту сообщается challenge (случайная последовательность байт), и он из этой строки и своего пароля вычисляет хэш-ответ, который потом проверяется сервером. Т.е. авторизация односторонняя. Клиент никак не может проверить, что сервер — именно тот (это функция IPSEC, который провайдерами не используется).

Поэтому да, обман клиентов и переключение их на себя теоретически возможен, причем не только в PPPoE, а вообще в любых автонастраиваемых протоколах, где используются бродкасты (DHCP, WPAD, IPv6 RAD и т.д.), и борьба с таким обманом очевидна — в провайдерском концентраторе должны быть заблокированы бродкасты соответствующих протоколов. На практике у провайдеров в домовых сетях часто разрешены многие широковещательные протоколы, которые тоже хорошо бы запретить (например, NetBIOS). Билайн сейчас активно внедряет в домовых сетях IP-телевидение, так вот эти TV-приставки тоже активно шумят в сети — в бродкастах сообщают, что именно смотрит юзер, сколько у него места на диске осталось, и т.д. :)
ayc, спасибо. Я именно бродкасты на адрес FF:FF:FF:FF:FF:FF и имел в виду.

Вот интересно попробовать на своем провайдере чисто из академического интереса, но боюсь людей в черном. :)
Menraen выше написал, что действительно бывают такие случаи. И там же он написал правдоподобную отмазку для людей в черном — «случайно включил PPPoE вместо L2TP» :)
Случаи укладывания портов автоматом с последующей необходимостью объяснять в письменном виде провайдеру логику своих действий для возобновления доступа к Интернету — да, бывают. Так что дерзайте. Только учтите — «отмазка» проходит только 1 (один) раз.
Напоминает старую добрую прослушку телефонов
Вольнов, ты?
Есть такое мнение.
Каких провайдеров проверяли?
я так думаю, PPPOE — провайдеров шифрующих ВЕСЬ траффик попросту нет, т.к. скорости сейчас большие+траффик внутри локальной сети не ограничен — и никакая циска не сможет шифровать несколько десятков мегабит (несколько клиентов в доме).
Ну, раз есть провайдеры, которые шифруют весь трафик в PPTP (у меня такой), шифруют весь трафик в точках доступа wi-fi (все такие), то почему бы не быть и шифрации в других канальных протоколах…

Проблема там, кстати, не только в отсутствии шифрации, но и в отсутствии аутентификации сервера (сертификатов сервера), т.к. сессию можно перехватывать не только в середине, но и в самом начале — подменив сервер, можно шифровать трафик своим подставным сервером, т.е. просто галочка «требовать шифрование» клиента в этом случае не спасёт.
Пошел к соседу…
Голос приятный, как раз на утро.
Спасибо.
Отлично, нам будет над чем подумать с коллегами теперь))
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории