Найти неавторизованный DHCP-сервер [дубликат]
Возможный дубликат:
Как найти неавторизованный DHCP-сервер в моей сети?
Я знаю, что это серьезный шанс, но мы начнем.
За последнюю неделю или около того, пользователи, подключенные к определенному коммутатору в нашей сети (в ней четыре тупых коммутатора, и это затрагивает только некоторых, а не всех пользователей на одном коммутаторе), получают адреса DHCP от неавторизованного сервера DHCP.
Я физически проверил каждый кабель, подключенный к данному коммутатору, чтобы убедиться, что ни к одному из них не подключен маршрутизатор или точка Wi-Fi. Я знаю IP-адрес DHCP-сервера, но не могу его пропинговать, и у него нет веб-интерфейса.
Есть ли у кого-нибудь предложения о том, что я могу сделать, чтобы найти его или отключить? К сожалению, все коммутаторы неуправляемые, и, как уже говорилось, нет физического устройства (которое я могу найти), подключенного к чему-либо.
Это становится критичным, потому что это портит PXE-загрузку целой группы тонких клиентов.
Попробуйте к nmap, это с помощью-O для обнаружения операционной системы, может дать Вам лучшее представление о том, каково сервер это? Также выполнение стандартного сканирования портов могло бы помочь выяснить, каково это
-
1Единственный открытый порт равняется 67 (или отвечающий, по крайней мере) :( Я hadn' t думал о nmap-O хотя! I' ll дают ему движение – Mark Henderson♦ 12 January 2010 в 03:32
-
2Ahah! Это была Виртуальная машина, кто-то работал на их машине разработки. nmap имел информацию, в которой я нуждался в секундах.Замечательно! – Mark Henderson♦ 12 January 2010 в 03:46
-
3Ничего себе, как fricking раздражение - это. Абсолютно unfindable. – Satanicpuppy 12 January 2010 в 03:57
-
4рассмотрение MAC-адреса для выяснения поставщика также было бы хорошим способом знать, что это была виртуальная машина. Довольный Вы добрались до сути относительно него :D – Nick Kavadias 12 January 2010 в 06:17
То, что Вы не можете проверить с помощью ping-запросов его, не является проблемой.
(Эта процедура главным образом для управляемых коммутаторов, в случае Ваших немых переключателей, это не столь полезно, так как Вы не можете осмотреть таблицу бегунка..., но так или иначе.)
- выполненный ipconfig / все (или взгляд на системный журнал), отметьте IP-адрес, перечисленный "Сервером DHCP". Обычно это совпадает со шлюзом по умолчанию.
- попытайтесь проверить с помощью ping-запросов этот IP-адрес, проигнорировать результат.
- выполненный arp-a. MAC-адрес, перечисленный для IP, является Вашим жуликом сервер DHCP.
Так, в Вашем случае Вы не можете развить это с определением местоположения switchport и отключением его, но Вы, возможно, по крайней мере, искали поставщика MAC-адреса и найдете, что поставщик был чем-то как VMware или virtualbox.
Если у Вас есть поле, лежащее вокруг, можно установить https://roguedetect.bountysource.com/на нем, который уведомит Вас, если проблема как это произойдет в будущем.
-
1Интересный инструмент. We' ve получил центр блейда ESXI VMware, таким образом, я могу развернуть его на там с небольшой системной стоимостью, которая, конечно, поймала бы это в будущем.Спасибо. (p.s. это site' s сертификат истекает), – Mark Henderson♦ 12 January 2010 в 04:12
Ну, можно всегда пытаться проверить с помощью ping-запросов дерьмо из него и проверить blinky световые сигналы на маршрутизаторах. =P
traceroute показывает Вам что-нибудь?
-
1Эй there' s другая идея I hadn' t мысль. Поэтому я люблю ServerFault. Ничто в traceroute как it' s все все в одной коммутируемой сети. – Mark Henderson♦ 12 January 2010 в 04:05
Я знаю, что это было уже решено, но другое средство, когда Вы действительно не можете найти машину (знающий это - VM, не говорит Вам, что размещает, это идет), должен продолжать отправлять ему запросы DHCP и отключить каждый кабель в свою очередь, пока это не замолчало. Иногда просто необходимо возвратиться к сырым основам.