С чего все началось
Некоторое время назад в квартиру был проведен интернет от нового провайдера, ранее услуги интернета поставлялись в квартиру по технологии ADSL. Так как дома провожу мало времени, мобильный интернет был более востребован, чем домашний. С переходом на удаленку решил, что скорости в 50-60 Мб/с для домашнего интернета прям совсем мало и решил увеличить скорость. По технологии ADSL по техническим причинам скорость свыше 60 Мб/с поднять не получится. Было принято решение перейти на другого провайдера с другой заявленной скоростью работы и уже c предоставлением услуг не по ADSL.
Могло быть как-то по-другому
Связался с представителем интернет провайдера. Пришли монтажники, просверлили в квартиру отверстие, провели патч-корд RJ-45. Дали договор и указания с сетевыми настройками, которые нужно выставить на роутере (выделенный ip, шлюз, маску подсети и ip адреса своих DNS), взяли оплату за первый месяц работы и ушли. Когда я ввёл в домашний роутер выданные мне сетевые настройки, интернет ворвался в квартиру. Процедура первичного входа в сеть нового абонента показалась мне слишком простой. Никакой первичной авторизации произведено не было, а моим идентификатором был выданный мне ip адрес. Интернет работал быстро и стабильно.В квартире работал wifi-роутер и через несущую стену скорость соединения немного проседала. В один из дней, нужно было скачать файл размером в два десятка гигабайт. Я и подумал, почему бы не подключить идущий в квартиру RJ-45 напрямую в пк.
Знай ближнего своего
Загрузив весь файл, я решил ближе познакомиться с соседями по гнездам коммутатора.
В многоквартирные дома зачастую интернет-соединение идет от провайдера по оптике, заходит в коммутационный шкаф в один из коммутаторов и распределяется между подъездами, квартирами по Ethernet кабелям, если рассматривать самую примитивную схему подключений. Да, уже есть технология когда оптика идет прямиком до квартиры (GPON), но это пока не так повсеместно распространено.
Если брать очень сильно упрощенную топологию в масштабах одного дома, то выглядит это примерно так:
Выходит так, что клиенты данного провайдера, некоторые соседние квартиры, работают в одной локальной сети на одном коммутационном оборудовании.
Включив прослушивание интерфейса, подключенного напрямую к сети провайдера, можно увидеть летящий от всех хостов в сети широковещательный ARP трафик.
Провайдер решил особо не заморачиваться с разбиением сети на мелкие сегменты, поэтому в пределах одного коммутатора мог гулять широковещательный трафик с 253 хостов, если не считать выключенные, тем самым забивая полосу пропускания каналов.
Просканировав с помощью nmap сеть, определилось количество активных хостов из всего пула адресов, версия ПО и открытые порты главного коммутатора:
А где ARP там рядом и ARP-spoofing
Для осуществление дальнейших действий была использована утилита ettercap-graphical, есть и более современные аналоги, но данный софт привлекает своим примитивным графическим интерфейсом и простотой в использовании.
В первом столбце IP адреса всех откликнувшихся на пинг роутеры, во втором их физические адреса.
Физический адрес является уникальным, по нему можно собрать информацию о географическом местоположении роутера и прочее, поэтому в рамках данной статьи он будет скрыт.
Целью 1 добавляем основной шлюз с адресом 192.168.xxx.1, целью 2 добавляем один из других адресов.
Представляемся шлюзу как хост с адресом 192.168.xxx.204, но со своим MAC адресом. Затем пользовательскому роутеру представляемся как шлюз с адресом 192.168.xxx.1 со своим MAC. Детали данной уязвимости протоколоа ARP подробно разобраны в других статьях которые легко гуглятся.
В итоге всех манипуляций мы имеем трафик с хостов который идет через нас, предварительно включив форвардинг пакетов:
Да, почти везде уже используется https, но в сети еще полно других незащищенных протоколов. К примеру, тот же самый DNS c атакой DNS-spoofing. Сам факт возможности осуществления MITM атаки порождает множество других атак. Все становится ужаснее когда в сети доступно несколько десятков активных хостов. Стоит учесть, что это частный сектор, а не корпоративная сеть и не у всех стоят средства защиты обнаружения и противодействиям сопутствующим атакам.
Как это избежать
Данной проблемой должен быть обеспокоен провайдер, настроить защиту от подобных атак очень просто, в случае того же самого коммутатора Cisco.
Включение Dynamic ARP Inspection (DAI) позволило бы предотвратить подмену MAC адреса главного шлюза. Разбитие широковещательного домена на более мелкие сегменты предотвратило хотя бы распространение ARP трафика на все хосты подряд и уменьшение количества числа возможных для атаки хостов. Клиент в свою очередь может защититься от подобных манипуляций настроив VPN прямо на домашнем роутере, большинство устройств уже поддерживают данный функционал.
Выводы
Скорее всего, провайдерам нет до этого дела, все силы направлены на увеличение числа клиентов. Данный материал написан не с целью демонстрации атаки, а с целью напомнить, что даже сеть вашего провайдера может быть не очень безопасной для передачи ваших данных. Уверен, что найдется много мелких региональных поставщиков интернет-услуг, которые больше, чем необходимо для элементарной работы сетевого оборудования, ничего не сделали.
amarao
Если абоненты не порезаны по сегментам, то это уже очень большой фейл оператора. Дальше уже не нужно изобретать какие-либо циски или High End решения от длинка. Если абоненты видят друг друга на L2, то сеть живёт до первого дятла.
Очевидно, виланы тут плохо работают, и надо либо честную l3-fabric делать, либо городить vxlan/qnq (в зависимости от того, что дешевле на оконечном оборудовании).
none7
На нормально настроенном оборудовании невозможно подделать ip или arp. Броадкаст флуд может быть зарезан по объёму, а мультикаст разрешён вообще только с сервера провайдера. Всё это есть в большинстве управляемого оборудования, это не Hi-End. Что тут сможет сделать дятел? Просто почему то админ данной сети допустил халатность, хотя абонентов подключают к умным коммутаторам именно из за слишком широких возможностей в L2.
Вроде бы переход на QinQ создаёт проблемы с мультикастом и придётся полностью отказаться от IPTV и перейти на интерактивное TV, а сеть то построена из расчёта по 1 мегабиту на нос, придётся расширять, клиентам приставки покупать. Зачем им это?
amarao
Ну, проблемы iptv на мультикасте обычно сводятся к тому, что мультикаст — это всегда проблемы.
Я знаю только одну вещь точно: как только в проекте появляется слово "мультикаст", в нём будет паролимпиада по его отладке. Обязательно.