Comments 63
Как вы узнали IP-адрес шлюза провайдера?
По tcpdump-у?
Всё верно, второй адрес в ppp подключение который и является роутом не передается в каждом пакете, там только мак pppoe сервера. Можно либо стимулировать клиента повторно авторизоваться с сервером, (например временно разорвав подключение) тогда этот адрес будет передан в IPCP-пакете, либо спросить у провайдера.
Он обычно не меняется. Можно просто узнать из легитимной сессии.
+100 к паранойи?
PPPoE не предназначен для использования в средах, где возможна такая врезка (читай: для FTTx). Отсюда и фигня.
В домовых сетях рулит и педалит DHCP + Option 82 и, соответственно, авторизация по порту коммутатора.
В домовых сетях рулит и педалит DHCP + Option 82 и, соответственно, авторизация по порту коммутатора.
Билайн как использовал PPTP, так и использовал.
Билайн — мудаки.
а как с таким перехватом дела на adsl линиях?
Будет посложнее, чем подклюение к своему ethernet'у, но принцип тот же.
Говорят, можно в разрез воткнуть DSLAM с зеркалированием порта.
DSLAM — штука не из дешёвых, хотя уже и продаётся в интернет-магазинах рядом с ковриками для мышей и стиральными машинами. А зеркалирование порта — это стандартная фича как-раз для lawful interception.
А в нашем городе в домовых сетях Билайн использует L2TP, а не PPTP. Хотя тоже без шифрования. PPTP и PPPoE — разные вещи, хотя отличия только в «конвертах».
Вроде бы L2TP и PPTP тоже можно перехватить (точнее, не перехватить, а «увести» к себе) тем же способом, т.к. авторизация (внутри PPP поверх L2TP) используется только в самом начале сессии, а в последующих пакетах идет только номер сессии.
Вроде бы L2TP и PPTP тоже можно перехватить (точнее, не перехватить, а «увести» к себе) тем же способом, т.к. авторизация (внутри PPP поверх L2TP) используется только в самом начале сессии, а в последующих пакетах идет только номер сессии.
Что-то не связывается:
dhcp — чтобы выдать адрес
option 82 — чтобы узнать с какого порта, какого коммутатора пришел dhcp запрос
авторизация по порту — разрешать инет или нет в зависимости от того, откуда пришел запрос
Каким образом это всё поможет от врезки в кабель до порта коммутатора? Через крокодильчики узнать MAC и всё остальное. Потом настроить сетевуху, обрезать, обжать подключиться вместо него и всё.
По-моему, даже легче чем с PPPoE. Что-то упустил?
dhcp — чтобы выдать адрес
option 82 — чтобы узнать с какого порта, какого коммутатора пришел dhcp запрос
авторизация по порту — разрешать инет или нет в зависимости от того, откуда пришел запрос
Каким образом это всё поможет от врезки в кабель до порта коммутатора? Через крокодильчики узнать MAC и всё остальное. Потом настроить сетевуху, обрезать, обжать подключиться вместо него и всё.
По-моему, даже легче чем с PPPoE. Что-то упустил?
Я-то думал, вы действительно PPPoE сломали, а тут незашифрованная сессия…
Простите за ламерский вопрос.
А что если кто-нибудь из пользователей провайдера поставит свой PPPoE-сервер, не получится ли ему подключить клиентов к себе? Такое возможно, кто знает? Или все/не все провайдеры блокируют такие вещи на коммутаторах?
А что если кто-нибудь из пользователей провайдера поставит свой PPPoE-сервер, не получится ли ему подключить клиентов к себе? Такое возможно, кто знает? Или все/не все провайдеры блокируют такие вещи на коммутаторах?
CHAP авторизация работает таким образом, что если обе стороны не знают комбинации логина-пароля подключится не удастся.
На своём PPoE сервере злоумышленник может просить именно PAP и если в клиенте не стоит «подключатьс только по CHAP» то вполне удастся узнать пароль. Другое дело, то можно наверное на свиах фильтровать это каким-т ообразом?
Да, CHAP-пароль вынюхать не получится, но Nastradamus спрашивал не об этом, а о «подключении клиентов к себе» — для этого пароль клиента знать не нужно, можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера». И дальше хакер может вынюхивать пароли пользователя на почту, веб-службы и т.д., если пользователь работает с ними без SSL/TLS. Поэтому если провайдер не блокирует бродкасты, то конечно подвергает своих клиентов риску.
Вы правы, я заблуждался. Мне всегда казалось что CHAP авторизация двухсторонняя.
можно ещё явно AC name указать в подключении. Если провайдер предоставляет данную информацию.
можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера».
Через этого «другого провайдера» клиент будет работать до первого обращения в техподдержку. При обращении же выяснится что клиент работает, а на BRAS-е сессии нет. Потом путём несложных манипуляций выясняется, «откуда кака прилетает» — т.е. откуда клиент получает PADO, и принимаются соответствующие меры.
Хотя практика показала, что «самозванными провайдерами» зачастую становятся не по злому умыслу, а по неумению — настраивают, к примеру, VPN на кошке, и выставляют наружу PPPoE вместо L2TP. И потом еще удивляются, за что им порт уложили.
Это понятно, что вскрыть размножение провайдеров легко. Хотя бы по самому факту бродкастов.
menraen: практика показала, что «самозванными провайдерами» зачастую становятся
Даже как-то не по себе стало от прочтения такой «частой практики». Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты, и не мониторит, и что факты таких приключений выясняются только при обращении клиента в техподдержку? Значит описанное в моем комменте ниже может случиться не только «теоретически»? Ой.
menraen: практика показала, что «самозванными провайдерами» зачастую становятся
Даже как-то не по себе стало от прочтения такой «частой практики». Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты, и не мониторит, и что факты таких приключений выясняются только при обращении клиента в техподдержку? Значит описанное в моем комменте ниже может случиться не только «теоретически»? Ой.
Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты
Какие броадкасты? PADO — вполне себе юникаст.
PADI бродкаст — его и надо блокировать (не пускать на порты других клиентов), тогда «альтернативные провайдеры» не смогут выслать в ответ PADO, и подмена сервера не состоится.
В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
Не совсем та-же. Блокировка DHCP-сервера представляет собой drop-анье offer-ов с untrusted портов, и относится производителями оборудования к L3-функционалу. Там же, где «последняя миля» терминируется на L2-устройстве, _обычно_ есть возможность лишь запретить _любое_ общение (мультикаст, броадкаст, юникаст) кроме как с аплинком (т.н. port isolation), что и делается на практике, и лишь изредка можно ставить фильтры по Ethertype, и то — настройка таких фильтров обычно выглядит как переключатель «allow all <-> PPPoE only».
Да, уровень другой, но принцип тот же…
Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны (не в смысле уязвимостей ОС, а в смысле уязвимостей сетевой инфраструктуры). Эдакая «ЛС без сисадмина»…
Значит наличие в сети соседских бродкастов означает, что port isolation отключен, и вообще ничего не фильтруется?
Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны (не в смысле уязвимостей ОС, а в смысле уязвимостей сетевой инфраструктуры). Эдакая «ЛС без сисадмина»…
Значит наличие в сети соседских бродкастов означает, что port isolation отключен, и вообще ничего не фильтруется?
Да, уровень другой, но принцип тот же…
Ваши бы слова, да производителям DSLAM-ов в уши…
Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны
Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах». Кроме того нужно понимать, что собственный провайдер — худшая из возможных целей для взлома по целому ряду причин (хотя это отнюдь не означает что провайдер не принимает мер для предотвращения взломов и других деструктивных действий).
Значит наличие в сети соседских бродкастов означает, что port isolation отключен
А где я сказал про _соседские_ броадкасты? ;)
> Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах».
Ну, фактически получается, что столь же беззащитны. Или даже менее, т.к. в самопальных домосетях предполагается близкое наличие энтузиастов, которые эти сети замутили, и значит имеют какую-то «моральную ответственность» перед соблазненными в сеть юзерами, в отличие от больших провайдеров, к которым и не дозвонишься обычно.
> А где я сказал про _соседские_ броадкасты? ;)
Это я говорил ранее — в комментариях ниже про шумящие бродкастами TV-приставки Билайна.
> собственный провайдер — худшая из возможных целей для взлома по целому ряду причин
Это понятно, я о том же и говорил, что легко детектируется. Но хотелось, бы, чтобы была техническая невозможность реализации указанных атак. Т.е. фильтрация «системных» бродкастов хотя бы. А если всё так, как вы пишете, то это довольно печально. Себя-то провайдер защитит, а вот соседей друг от друга — нет.
Ну, фактически получается, что столь же беззащитны. Или даже менее, т.к. в самопальных домосетях предполагается близкое наличие энтузиастов, которые эти сети замутили, и значит имеют какую-то «моральную ответственность» перед соблазненными в сеть юзерами, в отличие от больших провайдеров, к которым и не дозвонишься обычно.
> А где я сказал про _соседские_ броадкасты? ;)
Это я говорил ранее — в комментариях ниже про шумящие бродкастами TV-приставки Билайна.
> собственный провайдер — худшая из возможных целей для взлома по целому ряду причин
Это понятно, я о том же и говорил, что легко детектируется. Но хотелось, бы, чтобы была техническая невозможность реализации указанных атак. Т.е. фильтрация «системных» бродкастов хотя бы. А если всё так, как вы пишете, то это довольно печально. Себя-то провайдер защитит, а вот соседей друг от друга — нет.
Разумный провайдер всегда будет принимать разумные меры для защиты как себя, так и своих абонентов. Однако любой провайдер — в первую очередь коммерческая организация, и он при всём желании не может ставить 100% безопасность каждого конкретного клиента за основную цель. Осноная цель любого бизнеса — извлечение прибыли, и глупо ждать что при абонплате в среднем 5-10$ в месяц вы получите от провайдера state-of-the-art защиту от любых угроз, будете включены в «супер-умное» оборудование, умеющее «заглядывать» в заголовки до L7 включительно, и т.д. Кроме того, как опять-же показывает практика, безопасность — не та штука, которой «много не бывает», и собственные «благодарные» клиенты первыми побегут от «безопасного» провайдера к «опасному», но на котором «осёл» (к примеру) не ловит постоянно LowID.
Если же возвращаться к сабжу — да, такая атака принципиально возможна при совпадении ряда факторов, проверить совпадение которых не удастся до фактического совершения атаки — т.е. «или пан, или бан». Однако вероятность успешно, и главное — незаметно её провести ничтожно мала.
Ждать принятия провайдерами каких-либо дополнительных мер для предотвращения этого типа атак также, думаю, не стоит по уже упомянутым здесь причинам. Только если производители оборудования «почешутся». А они не почешутся, потому что от них в последнее время только и слышно что «PPPoE is dead, baby».
Если же возвращаться к сабжу — да, такая атака принципиально возможна при совпадении ряда факторов, проверить совпадение которых не удастся до фактического совершения атаки — т.е. «или пан, или бан». Однако вероятность успешно, и главное — незаметно её провести ничтожно мала.
Ждать принятия провайдерами каких-либо дополнительных мер для предотвращения этого типа атак также, думаю, не стоит по уже упомянутым здесь причинам. Только если производители оборудования «почешутся». А они не почешутся, потому что от них в последнее время только и слышно что «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-приставки тоже активно шумят в сети — в бродкастах сообщают, что именно смотрит юзер, сколько у него места на диске осталось, и т.д. :)
Поэтому да, обман клиентов и переключение их на себя теоретически возможен, причем не только в PPPoE, а вообще в любых автонастраиваемых протоколах, где используются бродкасты (DHCP, WPAD, IPv6 RAD и т.д.), и борьба с таким обманом очевидна — в провайдерском концентраторе должны быть заблокированы бродкасты соответствующих протоколов. На практике у провайдеров в домовых сетях часто разрешены многие широковещательные протоколы, которые тоже хорошо бы запретить (например, NetBIOS). Билайн сейчас активно внедряет в домовых сетях IP-телевидение, так вот эти TV-приставки тоже активно шумят в сети — в бродкастах сообщают, что именно смотрит юзер, сколько у него места на диске осталось, и т.д. :)
ayc, спасибо. Я именно бродкасты на адрес FF:FF:FF:FF:FF:FF и имел в виду.
Вот интересно попробовать на своем провайдере чисто из академического интереса, но боюсь людей в черном. :)
Вот интересно попробовать на своем провайдере чисто из академического интереса, но боюсь людей в черном. :)
Напоминает старую добрую прослушку телефонов
Вольнов, ты?
Каких провайдеров проверяли?
я так думаю, PPPOE — провайдеров шифрующих ВЕСЬ траффик попросту нет, т.к. скорости сейчас большие+траффик внутри локальной сети не ограничен — и никакая циска не сможет шифровать несколько десятков мегабит (несколько клиентов в доме).
Ну, раз есть провайдеры, которые шифруют весь трафик в PPTP (у меня такой), шифруют весь трафик в точках доступа wi-fi (все такие), то почему бы не быть и шифрации в других канальных протоколах…
Проблема там, кстати, не только в отсутствии шифрации, но и в отсутствии аутентификации сервера (сертификатов сервера), т.к. сессию можно перехватывать не только в середине, но и в самом начале — подменив сервер, можно шифровать трафик своим подставным сервером, т.е. просто галочка «требовать шифрование» клиента в этом случае не спасёт.
Проблема там, кстати, не только в отсутствии шифрации, но и в отсутствии аутентификации сервера (сертификатов сервера), т.к. сессию можно перехватывать не только в середине, но и в самом начале — подменив сервер, можно шифровать трафик своим подставным сервером, т.е. просто галочка «требовать шифрование» клиента в этом случае не спасёт.
Пошел к соседу…
Голос приятный, как раз на утро.
Спасибо.
Спасибо.
Отлично, нам будет над чем подумать с коллегами теперь))
UFO just landed and posted this here
Only those users with full accounts are able to leave comments. Log in, please.
Перехват PPPoE сессии