Перейти до

Как вычислить комп генерирующий мак адреса?


Рекомендованные сообщения

Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F, постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

Ссылка на сообщение
Поделиться на других сайтах
Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F, постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

поставь прогу ipguard !!!! рульная вещь !

сам в сетке ипользую

Ссылка на сообщение
Поделиться на других сайтах
Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F,  постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

поставь прогу ipguard !!!! рульная вещь !

сам в сетке ипользую

В сети и так существует привязка айпишника к маку и за этим следи сервак под линуксом сразу блокирует айпи с неверным маком или с невписаным айпишником. Но этот мак сервак не замечает и нарушения в логах не регистрирует. Мне кажется это или аналогичная прога банит всех или вирус новый....

Ссылка на сообщение
Поделиться на других сайтах

порывшись в логах сервака обнаружил вот такую запись

notice xl0 xx:xx:xx:xx:xx:xx 192.168.1.1 (47 pairs) fake de:ad:c8:56:64:02

что она значит ? (freebsd 5.4), xl0 -смотрит в локалку ...... :-0

Ссылка на сообщение
Поделиться на других сайтах
порывшись в логах сервака обнаружил вот такую запись

notice xl0 xx:xx:xx:xx:xx:xx 192.168.1.1 (47 pairs) fake de:ad:c8:56:64:02

что она значит ? (freebsd 5.4), xl0 -смотрит в локалку ...... :-0

И что это означает? Ктото под фрёй каку делает?

Ссылка на сообщение
Поделиться на других сайтах
Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F, постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

Очень похоже на логику работы L2NT :)

Это аналог IPGuard под Win32

Ссылка на сообщение
Поделиться на других сайтах
Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F,  постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

Очень похоже на логику работы L2NT :)

Это аналог IPGuard под Win32

А, нет, соврал. Там генерит только DEAD, а тут DEADBEEF, это вполне похоже на какой-то линукс, обычно они такое генерят в плане фейковых маков.

Ссылка на сообщение
Поделиться на других сайтах
Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F,  постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

Очень похоже на логику работы L2NT :)

Это аналог IPGuard под Win32

А, нет, соврал. Там генерит только DEAD, а тут DEADBEEF, это вполне похоже на какой-то линукс, обычно они такое генерят в плане фейковых маков.

А можно какимто образом вычислить эту машину? Или работать методом тыка, вычислить всех у кого стоит линух и во время очередной массовой блокировки отрубать?

Ссылка на сообщение
Поделиться на других сайтах
Возникла проблемка. В течении дня начинает появлятся конфликт айпи у многих пользователей. Мак адрес типа DE:AD:BE:EF:00:7F,  постоянно меняется, а именно, последние два знака. Выловить методом отключения не удаётся, так как конфликт не постоянный, а на протяжении 20-30 сек.

Каким образом можно выловить гада?

Ставить управляемое оборудование не предлагать! Может это новый вирус?

Очень похоже на логику работы L2NT :)

Это аналог IPGuard под Win32

А, нет, соврал. Там генерит только DEAD, а тут DEADBEEF, это вполне похоже на какой-то линукс, обычно они такое генерят в плане фейковых маков.

А можно какимто образом вычислить эту машину? Или работать методом тыка, вычислить всех у кого стоит линух и во время очередной массовой блокировки отрубать?

если сет ьна управляемых свичтах

вооружившись тспдампом вырубать порты:)

если нет это гемор еще тот:)))

Ссылка на сообщение
Поделиться на других сайтах

Определить примерное время суток, когда такое происходит.

Один запускает tcpdump на прослушивание arp трафика.

Второй отключает ветки сети на несколько минут.

Если ветку отключили, но пакеты проскальзывают, идем к следующей ветке.

Если отключили и перестали проскальзывать, можно подождать некоторое время для верности.

Потом отключать подветки и т.д.

Постепенно сужая радиус поиска.

Потом найти негодяя, дать люлей и отключить.

 

В сети на неуправляемых свичах это единственный вариант.

Потому что в такой сети единственные вещи, по которым можно определить комп - IP и MAC адрес.

И иикакое ПО вам ничего не покажет, если человек их меняет.

Ссылка на сообщение
Поделиться на других сайтах

А спасёт отца русской демократии установка какогото умного свитча в центр сети? Сеть более менее похожа на звезду. Сможет ли он определять с какого порта идёт перебор айпишек и подойдёт ли под эти нужды Длинк 3526?

Ссылка на сообщение
Поделиться на других сайтах

У этого свича есть port-security до 20 маков на порт. Если на каждом порту не больше 20 юзеров - должен подойти.

Более того, там есть ACL, можно попробовать с ним повозиться.

Правда я не знаю, как там всё это реализовано, надо пробовать.

Ссылка на сообщение
Поделиться на других сайтах
А спасёт отца русской демократии установка какогото умного свитча в центр сети?

Ну если cisco или microtic или что-нить типа тазика на *nix, то да)

Насчет остального - хз.

 

Прошу учесть - мое решение основано на той мысли, что сеть не на 50 компов и у простеньких л2 свичей может не хватить физических таблиц для всех мак или ip адресов.

Ссылка на сообщение
Поделиться на других сайтах
А спасёт отца русской демократии установка какогото умного свитча в центр сети?

Ну если cisco или microtic или что-нить типа тазика на *nix, то да)

Насчет остального - хз.

 

Прошу учесть - мое решение основано на той мысли, что сеть не на 50 компов и у простеньких л2 свичей может не хватить физических таблиц для всех мак или ip адресов.

к сожалению на одной из веток звезды висит около 400 машин, на остальных до 50.

Ссылка на сообщение
Поделиться на других сайтах
  • 2 years later...

Аналогично:

895 2009-11-13, 21:16:19 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-23-D9>, Port<9>)

894 2009-11-13, 21:16:17 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-8F-93>, Port<9>)

893 2009-11-13, 21:16:17 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-46-92>, Port<9>)

892 2009-11-13, 21:16:17 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-E4-40>, Port<9>)

891 2009-11-13, 21:16:16 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-4C-46>, Port<9>)

890 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-1F-54>, Port<9>)

889 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-D3-01>, Port<9>)

888 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-8D-BD>, Port<9>)

887 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-8A-F3>, Port<9>)

886 2009-11-13, 21:16:01 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-21-AD>, Port<9>)

 

1) Смена происходит так что у абонента в тот момент всё идеально работает и по старой связке ип + мак абонент доступен, а коммутатор блокирует только новую связку, выходит какбы данные адреса виртуальные и висят на том же устройстве.

2) В течении одной секунды может быть 5 и более смен мак адресов.

3) Пк абонента ради эксперимента проверенно почти всеми доступными антивирусами (нод, каспер, аваст, утилита от вебера керит, авира и прочие) результат один нет никакой заразы.

4) Данная проблема также загадочно исчезает как и появляется.

5) Из замеченного несколько таких абонентов на одном неуправляемом коммутаторе и он зависает напроч, если быть точным то всё же работает но пропускает примерно 1пинг из 100 и то не ковсем абонентам, избирательность ккому пропускать тот один из 100, а кому нет так и не ясна. Но вышестоящий управляемый коммутатор видит все ип и мак адреса за умершей мыльницей, ходя ни один из адресов не доступны(Предположительно изза переполнения мак таблицы в мыльнице)Коммутатору не легчает до перезагрузки по питанию.

6) В день прибавляется примерно по одному такому абоненту.

7) У кого какие мысли что это такое?

 

По поводу вопроса как вычислить, а очень просто найти обладателя мака 00-1D-92-74-ХХ-ХХ любой утилитой наподобие ipchmon

Ссылка на сообщение
Поделиться на других сайтах

сетевуха. Было у нас такое. Поменяли пошло. И что самое странное: комп был ВЫКЛЮЧЁН !!!.

 

Аналогично было несколько раз. Добавлю только что все сетевухи были встроенными в материнку.

Ссылка на сообщение
Поделиться на других сайтах

Аналогично:

895 2009-11-13, 21:16:19 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-23-D9>, Port<9>)

894 2009-11-13, 21:16:17 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-8F-93>, Port<9>)

893 2009-11-13, 21:16:17 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-46-92>, Port<9>)

892 2009-11-13, 21:16:17 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-E4-40>, Port<9>)

891 2009-11-13, 21:16:16 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-4C-46>, Port<9>)

890 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-1F-54>, Port<9>)

889 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-D3-01>, Port<9>)

888 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-8D-BD>, Port<9>)

887 2009-11-13, 21:16:02 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-8A-F3>, Port<9>)

886 2009-11-13, 21:16:01 Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<10.5.0.72>, MAC:<00-1D-92-74-21-AD>, Port<9>)

 

1) Смена происходит так что у абонента в тот момент всё идеально работает и по старой связке ип + мак абонент доступен, а коммутатор блокирует только новую связку, выходит какбы данные адреса виртуальные и висят на том же устройстве.

2) В течении одной секунды может быть 5 и более смен мак адресов.

3) Пк абонента ради эксперимента проверенно почти всеми доступными антивирусами (нод, каспер, аваст, утилита от вебера керит, авира и прочие) результат один нет никакой заразы.

4) Данная проблема также загадочно исчезает как и появляется.

5) Из замеченного несколько таких абонентов на одном неуправляемом коммутаторе и он зависает напроч, если быть точным то всё же работает но пропускает примерно 1пинг из 100 и то не ковсем абонентам, избирательность ккому пропускать тот один из 100, а кому нет так и не ясна. Но вышестоящий управляемый коммутатор видит все ип и мак адреса за умершей мыльницей, ходя ни один из адресов не доступны(Предположительно изза переполнения мак таблицы в мыльнице)Коммутатору не легчает до перезагрузки по питанию.

6) В день прибавляется примерно по одному такому абоненту.

7) У кого какие мысли что это такое?

 

По поводу вопроса как вычислить, а очень просто найти обладателя мака 00-1D-92-74-ХХ-ХХ любой утилитой наподобие ipchmon

 

Думаю что это вирус.

Последнее время во многих сетках такое наблюдается.

Коммутатор не вешается, то только такое впечитление.

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

 

Заражается как бы две машины, создается связка, исполнитель и жертва.

Если исполнитель включен, то при включении компа жертвы, та пробрасывает браткастовый пакет,

исполнитель получает пакет, и плюется пакетом с таким же маком.

Когда пакет попадает на коммутатор, то в таблице мак адресов, возникает две записи,

реальная указывающая на порт жертвы и левая указывающвя на порт исполнителя.

После этого пакеты для жертвы, коммутатор не передает, потому как его мак светится на двух портах.

 

Если жертв много, то забивает двойниками весь коммутатор, и сектор парализуется.

У мак записи есть время жызни, когда оно истекает, мак обнуляется и пинг проскакивает,

но перед пингом проскакивает арп запрос, в результате исполнитель получает брадкастовый пакет

и опять плюет левым пакетом с маком жертвы, пинги естественно пропадают.

 

Смена ип у жертвы нечего не дает, исполнитель работает на езернет уровне и ему пофиг какой ип будет у жертвы.

Спасает только перевод в другую подсеть, дабы исполнитель не получал браткастовый пакет.

 

Вычислить без умного коммутатора нереально.

 

Последнее время, месяца два, вирус модифицирован, запоминает ип жертвы, и при смене мака,

плюется новым маком но на тот же ИП.

 

Вирус похоже написан для локальных сетей,

жертва не имеет никаких вирусов, а у исполнителя вообще нет никаких проблем.

 

Если нет управляемых коммутаторов, лечение, переход на маску 32(255.255.255.255), с указанием шлюза.

Ссылка на сообщение
Поделиться на других сайтах

Простите за глупый вопрос, я с управляемыми коммутаторами дел не имел.

Но подходит время, когда следует подумать и о них, и о роутерах, разделяющих сеть на сегменты.

Поэтому вопроса два:

1. Какова вкратце - метода отлова такой заразы с управляемым коммутатором и известен ли кому-нить антивирусный пакет, который её реально ловит или хотя бы видит?

2. Какую железку посоветуете для разделения (100мбит, витая пара) на сегменты?

Сеть 10.0.0.0/255.255.255.0 (знаю что маска неправильная, просто пока так пашет - решили не переделывать), шлюз на FreeBSD.

Ссылка на сообщение
Поделиться на других сайтах

Простите за глупый вопрос, я с управляемыми коммутаторами дел не имел.

Но подходит время, когда следует подумать и о них, и о роутерах, разделяющих сеть на сегменты.

Поэтому вопроса два:

1. Какова вкратце - метода отлова такой заразы с управляемым коммутатором и известен ли кому-нить антивирусный пакет, который её реально ловит или хотя бы видит?

2. Какую железку посоветуете для разделения (100мбит, витая пара) на сегменты?

Сеть 10.0.0.0/255.255.255.0 (знаю что маска неправильная, просто пока так пашет - решили не переделывать), шлюз на FreeBSD.

 

Метода отлова,

анализ мак таблицы на управляемых коммутаторах,

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

Мак на левом порту указвает направление где находится исполнитель.

 

Исполнитель пробрасывает пакет именно с маком жертвы.

Дальше совсем плохо, нужно дропить пакет на входе с левым маком от исполнителя, а эта фунция еще реже.

 

По маске, правильная маска 10.0.0.0/255.255.255.0, у нее брадкаст 10.0.0.255, его слушают все машины в сетке,

если поставить маску 10.0.0.0/255.255.255.255, она неправильная, и брадкаст для ип 10.0.0.20 будет 10.0.0.20,

тоесть исполнитель не может прослушивать сеть, следовательно реагировать.

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

 

Можно использовать на постоянной основе, а можно просто использовать как меру.

 

Но опять же не факт что все так как описал,

год назад был первый случай,

и раз в три месяца проскакивал новый клиент,

а за последню неделю четыре случая.

Ссылка на сообщение
Поделиться на других сайтах

Теперь я понимаю почему некоторые владельцы сетей жертвуют самим принципом локалки ради стабильности передачи данных. Я говорю о запрете трафика между юзерами - локаль используют как среду передачи исключительно для Инета.

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

Предполагаю установку управляемого аппарата где-то в середине сети.

Надеюсь у меня получится диагностироать такие вещи удалённо.

 

Спасибо за информацию.

Ссылка на сообщение
Поделиться на других сайтах
  • 4 weeks later...

кто-то завел на своей машине ARP сервер и занимается спуфингом, бить таких надо если конечно это не делает админ , на 99.9% это http://l2nt.info/ т.к. там по умолчанию блокирует именно маком DEAD******** несоответствующий таблице маков хост в сети...

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...