Перейти к содержимому
Калькуляторы

fAnt1ksx

Пользователи
  • Публикации

    4
  • Зарегистрирован

  • Посещение

О fAnt1ksx

  • Звание
    Абитуриент
  1. Вот когда дело дойдет до трояна с арп-спуффингом, тогда ваш супер скрипт с алиасами на сетевку уже не поможет.
  2. Arp-spoffing

    Вообщем, есть такой троян: 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
  3. Лан тестеры за копейки могут прозвонить провод по жиле, это даст уверенность есть ли полный обрыв. Затем необходимо проверить провод на наличие срыва изоляции - если попала вода, может происходить обрыв связи и качество будет ужастное. Ну плюс сетевушку проверить. Плюс может коннектор был плохо обжат. И пары перекинуть оранжевую и зеленую на синюю и коричневую.
  4. Проблема не однократно обсуждалась и обмусоливалась на просторах интернета в целом и рунета в частности, но конкретного выхода из сложившейся ситуации мы пока не нашли. Вообщем, проблема в следующем: Предисловие: Имеем сеть, постоенную на преобладании не управляемых простых длинковских железок, плюс части управляемых свичей DES-3010G и DES-2108, плюс компексы. С самого начала сеть была несколько неверно спроектрированна и по бюджету нет возможности на каждый узел поставить управляемую железку. Проблема: уже как две недели назад начал пропадать гейт, в таблице динамической арп меняется мак адрес шлюза, на другой, что и, вероятно, является проблемой из-за которой коммутаторы (они же неуправляемые свичи) посылают поток данных вникуда или тому, чей это мак. Время и количество потерь изменялось со временем Что пытались: сначала думали, что сгорела какая-то из наших железок, но по проверке убедились, что это не так. После думали что это какой-то злоумышленник, который подменяет арп пакетами адрес шлюза и перенаправляет пакеты к себе, из-за чего пропадает шлюз. Но после установки нескольких управляемых железок в определенный сегмент убедились, что проблемы появляется стихийно с разных направлений, потери не постоянные и имеют разный характер как по количество времени спуффинга, так и по месторасположению. Подлило масла в огонь слова одного из знакомых сетевиков, что это некий троян.арп, который сам составляет на зараженной машине ложные арп пакеты и тем самым происходит переписывание арп-таблицы на маршрутизаторах. Вообщем, написал что сейчас пришло в голову сразу, возможно чтото еще добавлю в процессе обсуждения, но очень надеюсь на вашу помощь!