Подделка IP & MAC адресов. Применение Scotchlok

Новости.

Началась календарная весна. Хотя на Урале можно сказать, что зимы и не было. Вот и думай - то ли после неправильного лета, без жары и гроз, положена зима без морозов, то ли это уже всегда так будет...

Обзор тоже получился (против обыкновения) совсем простой по структуре. Одна дискуссионная тема и описание экспериментов со Scotchlok от 3m. Хочу постепенно изжить практику "растаскивания" материалов по нескольким выпускам - тяжело потом читателям понять все в целом.

Тем не менее, первый вопрос большой и серьезный. После описания коммутаторов с Vlan и SNMP было задано довольно таки много вопросов с общим смыслом - а зачем они, эти навороты буржуйские, вообще нужны. Сеть работает, трафик продается. Пользователь управляет авторизацией на сервере через браузер в SSL, или специальным скриптом-программкой. Да и трафик соседей вроде как обычным сниффером не просматривается...

Но война "щита и меча" далеко не закончилась. Пока будут потенциальные "дыры" в безопасности - успокаиваться рано.

Да еще как рано... Вот, например, достоверная информация о том, что в одной локальной сети, построенной на неуправляемых коммутаторах, одновременно, и особо не мешая друг, могут работать два узла с одинаковыми IP и MAC адресами.

Сильно колебался, стоит ли публиковать подобную информацию (вообще говоря, думал об этом более полугода). Знания можно реально использовать во вред, но... Политика страуса не даст результатов. Тем более, тема недавно стала достоянием известных в Рунете сетевых форумов. В любом случае, джинн вышел из бутылки.

С теоретической точки зрения, работа двух машин в одном хабе была понятна и без проверки. Но эксперимент был поставлен, и подтвердил справедливость: dns (udp) & icmp работает, tcp - нет.

Условия испытаний:
1 машина - Win2000 - IP/MASK, MAC
2 машина - FreeBSD.
На FreeBSD пишем: ifconfig rl0 IP/MASK lladdr MAC
И никаких проблем.

Кажется, только при инициализации TCP/IP стека винда кидает arp-request на наличие машин с таким же IP, и если получает ответ, то ругается и ничего не выставляет.

Наиболее важно объяснение работы TCP. Предположим, первая машина посылает TCP SYN на сервер, соответственно, оттуда приходит TCP SYN ACK. Этот пакет приходит в хаб, и все машины его видят.

По условиям, MAC & IP совпадают, и каждая машина пересылает пакет на 4-й уровень (т.е. на TCP layer) для дальнейшей обработки. Первая посылает в ответ TCP ACK, а вторая, естественно, TCP RST, т.к. считает этот пакет ошибочным (нет такой сессии). Как только на сервер приходит RST, тот сразу закрывает соединение. И пакеты, которые придут с первой машины, уже в свою очередь получат RST от сервера.

С DNS свои заморочки: там запрос и ответ в 1 пакет укладываются, И, когда приходит ответ, пассивная машина посылает icmp udp port unreachable. Но серверу уже все равно, на функциональности это не отразится.

Теперь работа с коммутатором. Те же компьютеры, но хаб меняется на switch Compex 2208A.

На одной машине запускаем сниффер, и слушаем. Со второй машины лезем в интернет. На первую ничего не приходит (понятно, коммутатор посылает все пакеты на вторую машину, т.к. помнит ее MAC в САМ-таблице).

Потом лезем с первой машины: тоже работает, причем вторая не видит ничего. Что будет, если сразу устанавливать 2 tcp сессии с двух машин, не проверял, можно будет проверить, если интересно.

PS. На второй машине видел tcpdump'ом broadcast'ы NetBIOS'а, но никакой ругани это не вызывало.

Тюкачев Андрей

Что же это означает в реальности? Да просто широчайшую возможность воровства трафика. Сети, с которых это можно было делать просто подставив IP, уже в прошлом. Привязка IP к МАС кое-где используется, но все понимают эфемерность такой защиты. Однако, авторизация на основе управления шлюзом весьма распространена, и считается достаточно надежной.

И вот проблема. Пользователей с одинаковыми IP и MAC, в сети из неуправляемых коммутаторов, невозможно отличить друг от друга на сервере. Просто никак. В какой-то степени спасет сеть, сделанная на хабах (или смешанная). Тогда одновременно смогут работать компьютеры только на разных ветках вышестоящего свитча (если он есть).

Более того, PPPoE не гарантирует безопастности. Конечно, жизнь сетевого "вора" он осложнит (организовать параллельный туннель не так-то просто). Но все зависит от цены вопроса, и рано или поздно какая-нибудь светлая голова напишет программу, делающую этот процесс доступным даже "продвинутому" подростку.

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

Почему совместная работа узлов с одинаковыми IP и МАС стала возможна на дешевых коммутаторах? Вопрос не слишком простой, внятного описания алгоритма работы неуправляемого свитча мне найти не удалось.

Можно предположить, что САМ-таблица (content-addressable memory) на самом деле одна, общая для всех портов. И может содержать в каждый момент времени только одну запись для каждого МАС-адреса. Это вполне логично - просто упорядочена эта таблица по адресу, использует его в качестве индекса при поиске. :-) Пришел адрес с другого узла - эффект равнозначен перетыканию разъема одного и того же компьютера в другой порт.

Соответственно, дубликат МАС в таблице автоматически прибивается (он просто не может существовать идеологически). И получается вполне себе поочередная работа (броадкасы хотят отдельно, и никому особо не мешают, как показано выше). Соответственно, соседи и шлюз никак не смогут отличить одного пользователя от другого. На IP уровне все спокойно, а TCP-сессии через локальную сеть проходят "в поле данных".

"Вредителю" нужно найти IP и MAC "жертвы" (задача более чем простая), и аккуратно их заменить. При активной совместной работе может быть заметно "притормаживание" - сессии все же рвутся. Но для малоактивного серфинга, и тем более ICQ, скорости более чем достаточно. А если "жертва" не проявляет особой активности, можно развернуться "по полной".

Такая вот невеселая история получается... А вот и последняя соломинка - письмо с форума iXBT, из-за которого немного пришлось задержать выпуск обзора.

Протестировал только что 2 рабочие станции. Windows 2000 Prof на каждой, IP & MAC совпадают, воткнуты в один свитч Compex 2208A, думаю на Catalist'е картина будет примерно такая же. (надо полагать, без настройки дополнительных фильтров. Прим. Nag)

Если сессии не пересекаются, то работает все просто замечательно. Ходишь по Inet'у и радуешься.

Когда обе машины начинают шариться по сети, то начинаются проблемы, как будто сидишь на плохом линке. Страница может не докачаться полностью. Если начинаешь скачивать файл, то коннект может обрываться в любой момент, стоит второй машине послать что-нибудь...

Если смотреть по netstat -s, то большое количество оборванных сессий (сниффер на роутере показывает проскакивающие TCP RST, когда пакет из TCP сессии на другую машинку попадает ), много Segments Retransmitted, Failed Connection Attempts и Reset Connections. Такая вот картинка.

Но в принципе, очень даже не плохо, если выделенка хорошая и сайт типа iXBT загружается за 2-3 секунды, то можно в инете почти на халяву сидеть.

Какие можно из этого сделать выводы? Применять для отслеживания "злодеев" эвристический анализ можно, но не слишком просто. Да и не эффективно для сколь-нибудь большой сети.

Есть, правда, один "крючочек". Если подделывать адреса "в лоб", без небольшой подготовки, это легко (и главное, удаленно) может определить администратор сети (или даже специальный робот).

Но об этом, думаю, писать подробно никак не стоит. Хоть какая-то небольшая защита должна остаться (тем более, это вроде бы нельзя сделать стандартными средствами windows).

Остается вернуться к тому, с чего начинался обзор. К смыслу применения управляемых коммутаторов. Фильтрация по МАС-адресу, или мониторинг через агента SNMP, эту дыру в защите полностью ликвидируют. Впрочем, защита от "воровства" трафика - не единственное применение этих устройств. Но об этом в следующих обзорах...

Использование Scotchlok.

Начало описания полезных "плюшек" от 3m начато в #68 от 03 февраля. Но теория это немного не то, что нужно. Поэтому, разжился у старого знакомого парой "плюшек" и решил попробовать соединить П-296 и обычную витую пару.