Предыдущий выпуск / Поиск по сайту

nag@nag.ru, 04 марта 2002

Каждому соединению - по соединителю.

#74. Новости.

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

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

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

Да еще как рано... Вот, например, достоверная информация о том, что в одной локальной сети, построенной на неуправляемых коммутаторах, одновременно, и особо не мешая друг, могут работать два узла с одинаковыми 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 к МАС кое-где используется, но все понимают эфемерность такой защиты. Однако, авторизация на основе управления шлюзом весьма распространена, и считается достаточно надежной.

Кабель П-296, П-270. Возможна отправка почтово-багажным вагоном по России. Стоимость 12,50 рублей за один метр, при оптовых объемах - обоснованный торг. Минимальная партия - 500 метров (катушка). Посмотреть описание можно тут. Заказать

И вот проблема. Пользователей с одинаковыми 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 секунды, то можно в инете почти на халяву сидеть.

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

$900 Cisco NM-1FE-TX (NM-1FE-FX).

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

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

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

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

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

Как оказалось, используются Scotchlok'и на один провод (а не на пару, как я думал сначала). Говорят, что так удобнее (не думаю) и дешевле (охотно верю).

Процесс зачистки П-296 показывать не буду. Уж как-нибудь в другой раз. ;-) А на витой паре лишь снял внешнюю оболочку. Ничего более не зачищалось.

Особо мудрствовать не стал. Примерно подровнял хвостики на длину отверстий Scotchlok'а, засунул проводник витой пары и зачищенный П-296 в "плюшку". Протолкнул до упора.

$275 3com Super Stack II 1100 (3C16950).

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

Зажимаю обычными плоскогубцами. Давлю "от души". Все нормально, кнопка уходит до упора, гель выступает капельками из отверстий на проводники (как говорят, он не смываться водой). Подергал за кабеля - вроде все крепко, выпадывать ничего не собирается.

Не останавливаясь, заправил концы проводников во второй Scotchlok, и сразу их обжал. Тот же эффект.

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

В принципе, если подходить аккуратно и строго, можно шутя уложиться в норму расплетения для Cat 5 (1,2 см). Потери будут никак не больше, чем в любимом 110 кроссе.

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

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

Но что будет, если просто соединять на Scotchlok вообще без изоленты? Просто обжать, и оставить, как получилось?

На вид не слишком надежно. Однако, простая попытка порвать (причем "на излом" отверстия) ни к чему не привела. Как видно на фотографии, проводники порвались за соединителем. Ни корпус Scotchlok, ни зажим (к моему немалому удивлению) не пострадали. Прочный пластик, 3m не обманули в рекламном проспекте.

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

И самое интересно - так и не удалось найти эти приспособления в магазинах Екатеринбурга. Продавцы даже про них ничего не слышали... :-)

Обсудить в форуме

Анонс

Практический материал из Днепропетровска. На сей раз, будет показана установка активного оборудования. (как раз то, что не попало в этот выпуск из-за недостатка места).