fAnt1ksx Опубликовано 5 августа, 2008 (изменено) · Жалоба Проблема не однократно обсуждалась и обмусоливалась на просторах интернета в целом и рунета в частности, но конкретного выхода из сложившейся ситуации мы пока не нашли. Вообщем, проблема в следующем: Предисловие: Имеем сеть, постоенную на преобладании не управляемых простых длинковских железок, плюс части управляемых свичей DES-3010G и DES-2108, плюс компексы. С самого начала сеть была несколько неверно спроектрированна и по бюджету нет возможности на каждый узел поставить управляемую железку. Проблема: уже как две недели назад начал пропадать гейт, в таблице динамической арп меняется мак адрес шлюза, на другой, что и, вероятно, является проблемой из-за которой коммутаторы (они же неуправляемые свичи) посылают поток данных вникуда или тому, чей это мак. Время и количество потерь изменялось со временем Что пытались: сначала думали, что сгорела какая-то из наших железок, но по проверке убедились, что это не так. После думали что это какой-то злоумышленник, который подменяет арп пакетами адрес шлюза и перенаправляет пакеты к себе, из-за чего пропадает шлюз. Но после установки нескольких управляемых железок в определенный сегмент убедились, что проблемы появляется стихийно с разных направлений, потери не постоянные и имеют разный характер как по количество времени спуффинга, так и по месторасположению. Подлило масла в огонь слова одного из знакомых сетевиков, что это некий троян.арп, который сам составляет на зараженной машине ложные арп пакеты и тем самым происходит переписывание арп-таблицы на маршрутизаторах. Вообщем, написал что сейчас пришло в голову сразу, возможно чтото еще добавлю в процессе обсуждения, но очень надеюсь на вашу помощь! Изменено 5 августа, 2008 пользователем fAnt1ksx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Starcrafter Опубликовано 5 августа, 2008 · Жалоба Такая же ситуация в одном из сегментов. Гейт под микротиком. В момент шторма все ІР адреса на интерфейсе гейта имеют одинаковый мак. Хотя сеть все равно исправно работает. Но рано или поздно приходит момент, когда гейт пропадает. Помогает принудительная очистка АРП кеша на гейте. Мак от шторма к шторму меняется на другой. Пробовал разбивать сеть на сегменты, так как думал что мыльница или лан карта глючит какая нибуть. Доразбивался до того, что в обоих кусочках сети ситуация повторялась. ЗЫ. Меня тоже посещала мысль о трояне... :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fAnt1ksx Опубликовано 5 августа, 2008 (изменено) · Жалоба Вообщем, есть такой троян: Trojan-Downloader.JS.Timul.cv и похожие, у некоторых вываливают при посещении внутреннего сайта сети, модифицируя страницу с припиской в хтмл код ява скрипта, которого там на самом деле нет. Как писалось в этой теме, эти бацилоносители и портят сеточку. И, как бы, в момент флуда в тисипидампе на сервере вылетает много айпи с одного мака, а на машине, которая теряет связь до гейта - меняется мак шлюза на другой в списке арп -а. Как бы все сделать более автоматизированно и четко? Желательно совет соответсвенно тому оборудованию, что я написал в первом посте. Кстати, читал http://xgu.ru/wiki/ARP-spoofing , там сказано, что "Функция port-security коммутатора позволяет защититься от смены MAC-адреса на порту коммутатора. В том случае если компьютер, подключенный к порту коммутатора меняет MAC-адрес или если меняется компьютер, коммутатор замечает подмену и перестаёт передавать пакеты отправленные с новым обратным адресом. Кроме этого, могут выполняться другие действия: отсылка SNMP-трапа, запись в syslog и тому подобное. При ARP-spoofing'е MAC-адрес отправителя (атакующего) не меняется и поэтому с точки зрения port-security никаких аномалий нет. Функция port-security никак не отвечает за соответствие IP-адресов и MAC-адресов, а атака ARP-spoofing построена именно на этом." Тогда как же быть? Update: вообщем, вирус, которые это делает, как я понял - этот http://www.virustotal.com/ru/analisis/3699...a9168b8d222f9a3 http://forum.antichat.ru/nextnewesttothread79394.html Изменено 5 августа, 2008 пользователем fAnt1ksx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Fog Опубликовано 6 августа, 2008 · Жалоба такой троян дейсвительно есть. вычислить проблемного клиента можно посмотрев снифером локалку (будут присуствовать пакеты с протоколом 1702). если это троян то у него будет одновременно 2 ответа с одинаковым МАС. причем первый ответ будет с ИП нарушителя второй будет с иП шлюза. если это используется прога для снифа и перенаправления трафика то пакеты 1702 небудут. положение плохо тем что подменяя МАС шлюза на свой это есть механизм размножения для него. так что вам помогут статическая привязка МАС шлюза у клиентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...