Обнаружение новых DHCP-серверов в локальной сети

Просканируй сеть tcpdumpom на предмет обнаружения открытых портов на которых работает dhcpd

> Просканируй сеть tcpdumpom

ты имел ввиду nmap ?

Проблема в том, что хостов очень много.

> tcpdumpom на предмет обнаружения открытых портов на которых работает dhcpd

Вывод "tcpdump udp" писать в файл накладно, а на:

# tcpdump -q udp | grep "bootps"

не могу навесить дополнительных фильтров, конвейер перестаёт выводить что-либо, вообще. :(

А разве на свитчах tcpdump ответы другим машинам от DHCPD выловит? Или у вас там хабы?

> А разве на свитчах tcpdump ответы другим машинам от DHCPD выловит? Или у вас там хабы?

Цепляйся на центральный коммутатор и выловишь что-нибудь :)

Я бы попробовал воткнуть сетевую карточку (которой валидный не даст адрес) и ждал бы пока она не получит IP...

Не нужно писать вывод tcpdump в файл слишком долго. Нужно включить tcpdump (вывод в файл, можно с фильтром), включить комп, когда комп получит адрес, выключить tcpdump. Посмотреть в файле какие сервера ответили на запрос адреса. Я думаю, что если в сети 3 dhcp сервера, то на один запрос ответят все 3, запросивший хост получит адрес от первого ответившего и будет использовать полученный от него адрес, но ответят все 3 сервера. Эти ответы и надо определить по содержимому файла.

Я хотел было повесить процесс на парсинг непрерывного конвейера

# tcpdump -lq udp 2>1 | grep "bootps >" | grep -v "[valid-dhcpd]"

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

При всём этом, "разовый" сенсор, типа:

# tcpdump -lq -c 1000 udp 2>1 | grep "bootps >" | grep -v "[valid-dhcpd]"

,отрабатывает 1000 пакетов нормально, но не долго :) , посему, есть высокая вероятность потери информации.

Есть какие-либо идеи, или это у меня уникальная проблема с "непрерывным конвейером"?

Или я дурак, или одно из двух. Почему бы не написать:
tcpdump -i eth0 -n udp and port 67 and src host ! 192.168.0.1 (IP валидного сервера)
Этот вывод не остановится до тех пор, пока не ломанут tcpdump ;)

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

Не нужно делать pipe для tcpdump, запись в файл чем не устраивает?

Видимо я плохо объяснил :( Топология и загрузка сети не имеет значение. Важно, чтобы в точке прослушки tcpdump-ом был ВЕСЬ UDP трафик! Тогда предложенные мной (см. выше) опции tcpdump-а отобразят все ответы НЕвалидных DHCP серверов. Ни каких пайпов и файлов. Вывод будет идти на консоль. При желании его можно обрабатывать скриптом, например для отсылки SMS или просто почты.

# tcpdump -i eth0 -n udp and src port 67 and src host ! 192.168.0.1

> Ни каких пайпов и файлов. Вывод будет идти на консоль. При желании его можно обрабатывать скриптом, например для отсылки SMS или просто почты.

Может я сильно туплю под вечер...

Но, как без пайпов и файлов его обработать (можно пример, plz)?

Я знака ! в параметрах не заметил.)
Твой вариант правильный.

Да его не надо обрабатывать он будет выводить только ответы невалидных серверов. Если ничего не выводит, значит их нет.

> Если ничего не выводит, значит их нет.

Это всё верно :)

> Да его не надо обрабатывать он будет выводить только ответы невалидных серверов.

Однако, мысль в том, чтоб повесить обработчик события. Например: popup, mail, sms или "arp -- MAC -- snmp -- block_port", т.е., хотя бы частично, автоматизировать процесс :)

"Однако, мысль в том, чтоб повесить обработчик события. Например: popup, mail, sms или "arp -- MAC -- snmp -- block_port", т.е., хотя бы частично, автоматизировать процесс :) "

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

FUNKY, спасибо :)

> Наверное, тогда вывод в файл с периодическим сканированием его содержимого на наличие новых записей с последуещей желаемой обработкой этих записей.

Угумс. Только, суть, как раз в том, что у меня есть проблемы с адекватной записью в файл или обработкой конвейером :(

Вот, я и пытаюсь выяснить, это только у меня так, или не только у меня... :|

В общем,

# tcpdump -i eth0 -n udp and src port 67 and src host ! 192.168.0.1 > ~/dhcp.rpt

ничего не пишет в файл,

# tcpdump -i eth0 -n udp and src port 67 and src host ! 192.168.0.1 | cut -d" " -f2

... и так далее, ничего не выводит.

Вот.

Так может у тебя и нет других dhcp серверов кроме того, что указан в команде. Вот и вывода нет.

> Так может у тебя и нет других dhcp серверов кроме того, что указан в команде. Вот и вывода нет.

Не надо так опошлять идею :D Их у меня три штуки. :)

Суть в другом:

# tcpdump -i eth0 -n udp and src port 67 > ~/dhcp.rpt

ничего не пишет в файл (в смысле, с приемлемой синхронностью с событием),

# tcpdump -i eth0 -n udp and src port 67 | cut -d" " -f2

ничего не выводит (аналогично).

Не могу понять, откуда такая буферизация и как с ней бороться :(

У кого-нибудь эта проблема воспроизводится?

P.S. Собственно, вопрос в том, как победить буферизацию.

man tcpdump

-skip-

-l Make stdout line buffered. Useful if you want to see the data
while capturing it. E.g.,
``tcpdump -l | tee dat'' or ``tcpdump -l >
dat & tail -f dat''.

-skip-