Провайдеров с PPPoE в нашем регионе нет вообще, самопальные домовые сети раздают IP по DHCP, статистику считают по IP на шлюзах, старейшие «автохтонные» провайдеры региона (не домовые сети, а «наследники» телефонных пулов, сейчас у них у всех оптоволокно до большинства многоэтажек в городе, т.е. в каждом доме 4-5 провайдеров на выбор) раздают интернет по PPTP, единственный «телеком» на домашнем рынке — Билайн, у него L2TP. При этом у Билайна локальным считается весь внутригородской трафик по билайновской сети (включая трафик между клиентами — торренты и DC в основном) и до пары московских («личный кабинет»), а остальные билайновские сайты маршрутизируются по не-локальным IP, и в статистике считаются как внешние. Пиринга с местными провайдерами у билайна нет, к ним все идет через Питер+Москву. Ну то есть, у нас получается все наоборот, в сравнении с вашей картиной.
Ну IP-то DHCP выдаст, а дальше? Смысл всех этих VPNов и прочих виртуальных каналов в том, чтобы клиент вводил «пароль для интернета», а локальный трафик чтобы шел отдельно. Если от такой схемы отказываться, то провайдерам придётся менять все учетные схемы и тарифные планы, так?
> Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах».
Ну, фактически получается, что столь же беззащитны. Или даже менее, т.к. в самопальных домосетях предполагается близкое наличие энтузиастов, которые эти сети замутили, и значит имеют какую-то «моральную ответственность» перед соблазненными в сеть юзерами, в отличие от больших провайдеров, к которым и не дозвонишься обычно.
> А где я сказал про _соседские_ броадкасты? ;)
Это я говорил ранее — в комментариях ниже про шумящие бродкастами TV-приставки Билайна.
> собственный провайдер — худшая из возможных целей для взлома по целому ряду причин
Это понятно, я о том же и говорил, что легко детектируется. Но хотелось, бы, чтобы была техническая невозможность реализации указанных атак. Т.е. фильтрация «системных» бродкастов хотя бы. А если всё так, как вы пишете, то это довольно печально. Себя-то провайдер защитит, а вот соседей друг от друга — нет.
Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны (не в смысле уязвимостей ОС, а в смысле уязвимостей сетевой инфраструктуры). Эдакая «ЛС без сисадмина»…
Значит наличие в сети соседских бродкастов означает, что port isolation отключен, и вообще ничего не фильтруется?
А, понял, это ответ на моё " Хотя бы по самому факту бродкастов."? Да, там неправильно, атакующий «альтернативный провайдер» может обойтись без бродкастов, если бродкасты от клиентов не блокируются.
PADI бродкаст — его и надо блокировать (не пускать на порты других клиентов), тогда «альтернативные провайдеры» не смогут выслать в ответ PADO, и подмена сервера не состоится.
В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
AC name можно и из записи сессии выяснить, если провайдер его не сообщает. Но к сожалению ничто не помешает злоумышленнику указать то же самое имя концентратора, там ведь никакими ЦП идентификация не защищается.
Menraen выше написал, что действительно бывают такие случаи. И там же он написал правдоподобную отмазку для людей в черном — «случайно включил PPPoE вместо L2TP» :)
Это понятно, что вскрыть размножение провайдеров легко. Хотя бы по самому факту бродкастов.
menraen: практика показала, что «самозванными провайдерами» зачастую становятся
Даже как-то не по себе стало от прочтения такой «частой практики». Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты, и не мониторит, и что факты таких приключений выясняются только при обращении клиента в техподдержку? Значит описанное в моем комменте ниже может случиться не только «теоретически»? Ой.
Это понятно. Но TCP ресурсоемкий не только из-за каких-то устаревших вещей типа контрольных сумм (которые сейчас перекладываются на сетевушку, и не отвлекают процессор), но и из-за таких вещей как потери пакетов (из-за congestion, который никуда не делся за эти десятилетия), которую в любом альтернативном надежном протоколе все равно надо как-то компенсировать. Т.е. просто тупо быстро флудить кадрами в LPX не получится, буфера свича забьются, нужен какой-то flow control, который добавит оверхед, сравнимый с TCP (ну или с торрентным uTP :).
Вообще мой исходный коммент не о том, какой протокол проще или быстрее, а о том, что лучше все-таки иметь TCP/IP в дополнение к самодельным простым/быстрым протоколам.
Ну, раз есть провайдеры, которые шифруют весь трафик в PPTP (у меня такой), шифруют весь трафик в точках доступа wi-fi (все такие), то почему бы не быть и шифрации в других канальных протоколах…
Проблема там, кстати, не только в отсутствии шифрации, но и в отсутствии аутентификации сервера (сертификатов сервера), т.к. сессию можно перехватывать не только в середине, но и в самом начале — подменив сервер, можно шифровать трафик своим подставным сервером, т.е. просто галочка «требовать шифрование» клиента в этом случае не спасёт.
Да, CHAP-пароль вынюхать не получится, но Nastradamus спрашивал не об этом, а о «подключении клиентов к себе» — для этого пароль клиента знать не нужно, можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера». И дальше хакер может вынюхивать пароли пользователя на почту, веб-службы и т.д., если пользователь работает с ними без SSL/TLS. Поэтому если провайдер не блокирует бродкасты, то конечно подвергает своих клиентов риску.
CHAP-авторизация работает таким образом, что клиенту сообщается challenge (случайная последовательность байт), и он из этой строки и своего пароля вычисляет хэш-ответ, который потом проверяется сервером. Т.е. авторизация односторонняя. Клиент никак не может проверить, что сервер — именно тот (это функция IPSEC, который провайдерами не используется).
Поэтому да, обман клиентов и переключение их на себя теоретически возможен, причем не только в PPPoE, а вообще в любых автонастраиваемых протоколах, где используются бродкасты (DHCP, WPAD, IPv6 RAD и т.д.), и борьба с таким обманом очевидна — в провайдерском концентраторе должны быть заблокированы бродкасты соответствующих протоколов. На практике у провайдеров в домовых сетях часто разрешены многие широковещательные протоколы, которые тоже хорошо бы запретить (например, NetBIOS). Билайн сейчас активно внедряет в домовых сетях IP-телевидение, так вот эти TV-приставки тоже активно шумят в сети — в бродкастах сообщают, что именно смотрит юзер, сколько у него места на диске осталось, и т.д. :)
А как проект связан с ReactOS?
ren *.txt *.html
Это даже в DOS'е работало (с трехсимвольными расширениями, конечно, html не пойдёт). Сейчас проверил на Windows 8 — по прежнему работает :)
Ну, фактически получается, что столь же беззащитны. Или даже менее, т.к. в самопальных домосетях предполагается близкое наличие энтузиастов, которые эти сети замутили, и значит имеют какую-то «моральную ответственность» перед соблазненными в сеть юзерами, в отличие от больших провайдеров, к которым и не дозвонишься обычно.
> А где я сказал про _соседские_ броадкасты? ;)
Это я говорил ранее — в комментариях ниже про шумящие бродкастами TV-приставки Билайна.
> собственный провайдер — худшая из возможных целей для взлома по целому ряду причин
Это понятно, я о том же и говорил, что легко детектируется. Но хотелось, бы, чтобы была техническая невозможность реализации указанных атак. Т.е. фильтрация «системных» бродкастов хотя бы. А если всё так, как вы пишете, то это довольно печально. Себя-то провайдер защитит, а вот соседей друг от друга — нет.
Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны (не в смысле уязвимостей ОС, а в смысле уязвимостей сетевой инфраструктуры). Эдакая «ЛС без сисадмина»…
Значит наличие в сети соседских бродкастов означает, что port isolation отключен, и вообще ничего не фильтруется?
В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
menraen: практика показала, что «самозванными провайдерами» зачастую становятся
Даже как-то не по себе стало от прочтения такой «частой практики». Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты, и не мониторит, и что факты таких приключений выясняются только при обращении клиента в техподдержку? Значит описанное в моем комменте ниже может случиться не только «теоретически»? Ой.
Вообще мой исходный коммент не о том, какой протокол проще или быстрее, а о том, что лучше все-таки иметь TCP/IP в дополнение к самодельным простым/быстрым протоколам.
Проблема там, кстати, не только в отсутствии шифрации, но и в отсутствии аутентификации сервера (сертификатов сервера), т.к. сессию можно перехватывать не только в середине, но и в самом начале — подменив сервер, можно шифровать трафик своим подставным сервером, т.е. просто галочка «требовать шифрование» клиента в этом случае не спасёт.
Поэтому да, обман клиентов и переключение их на себя теоретически возможен, причем не только в PPPoE, а вообще в любых автонастраиваемых протоколах, где используются бродкасты (DHCP, WPAD, IPv6 RAD и т.д.), и борьба с таким обманом очевидна — в провайдерском концентраторе должны быть заблокированы бродкасты соответствующих протоколов. На практике у провайдеров в домовых сетях часто разрешены многие широковещательные протоколы, которые тоже хорошо бы запретить (например, NetBIOS). Билайн сейчас активно внедряет в домовых сетях IP-телевидение, так вот эти TV-приставки тоже активно шумят в сети — в бродкастах сообщают, что именно смотрит юзер, сколько у него места на диске осталось, и т.д. :)