Sprawdź, czy serwer DHCP istnieje w mojej sieci przy użyciu bash

23

używając CentOS ze statycznym adresem IP, czy jest jakiś sposób na określenie, czy serwer DHCP działa w sieci za pomocą bash?

Steve
źródło

Odpowiedzi:

44

nmap robi to łatwo:

sudo nmap --script broadcast-dhcp-discover -e eth0

pokaże:

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-16 09:25 UTC
Pre-scan script results:
| broadcast-dhcp-discover: 
|   IP Offered: 192.168.14.67
|   DHCP Message Type: DHCPOFFER
|   Server Identifier: 192.168.14.1
|   IP Address Lease Time: 0 days, 0:05:00
|   Subnet Mask: 255.255.255.0
|   Router: 192.168.14.1
|   Domain Name Server: 193.190.127.150
|   Domain Name: maas
|   Broadcast Address: 192.168.14.255
|_  NTP Servers: 91.189.91.157, 91.189.89.199, 91.189.94.4, 91.189.89.198
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.27 seconds
Merlijn Sebrechts
źródło
1
Chociaż istniejące odpowiedzi były dość dobre, zdecydowanie wolę twoje rozwiązanie!
Julie Pelletier,
1
Dobra komenda, ale warto zauważyć, że to tylko pierwszy serwer DHCP, który odpowiada. Jeśli istnieje wiele serwerów DHCP, to polecenie ich nie znajdzie.
poke
6

Jeśli jest dostępny w repozytorium, istnieje dhcpdump

ze strony man:

SYNOPSIS
       dhcpdump [-h regular-expression] -i interface

DESCRIPTION
       This command parses the output of tcpdump to display the dhcp-packets for easier checking and debugging.

USAGE
       dhcpdump -i /dev/fxp0

       If you want to filter a specific Client Hardware Address (CHADDR), then you can specifiy it as a regular expressions:

       dhcpdump -i /dev/fxp0 -h ^00:c0:4f

       This will display only the packets with Client Hardware Addresses which start with 00:c0:4f.
Pol Hallen
źródło
5

Jeśli masz tcpdumpdo dyspozycji, wywołanie programu jako root z następującymi parametrami może pomóc w znalezieniu serwera:

tcpdump -i [identyfikator interfejsu] - nowy port udp 68

Niestety z powodu układu mojej sieci nie mogę od razu zarejestrować pełnego uścisku dłoni DHCP. Widzę jednak żądanie DHCP z mojego iPada:

22:16:44.767371 30:10:e4:8f:02:14 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 255, id 15652, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 30:10:e4:8f:02:14, length 300, xid 0x42448eb6, Flags [none]
      Client-Ethernet-Address 30:10:e4:8f:02:14
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Parameter-Request Option 55, length 6: 
          Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
          Option 119, Option 252
        MSZ Option 57, length 2: 1500
        Client-ID Option 61, length 7: ether 30:10:e4:8f:02:14
        Requested-IP Option 50, length 4: 192.168.2.222
        Lease-Time Option 51, length 4: 7776000
        Hostname Option 12, length 15: "NevinWiamssiPad"

Po pozwoleniu `tcpdump 'na działanie przez noc, w końcu zobaczyłem to ACK:

07:46:40.049423 a8:39:44:96:fa:b8 > 68:a8:6d:58:5b:f3, ethertype IPv4 (0x0800), length 320: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 306)
    192.168.2.1.67 > 192.168.2.22.68: BOOTP/DHCP, Reply, length 278, xid 0x5e7944f, Flags [none]
      Client-IP 192.168.2.22
      Your-IP 192.168.2.22
      Client-Ethernet-Address 68:a8:6d:58:5b:f3
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.2.1
        Lease-Time Option 51, length 4: 86400
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 192.168.2.1
        Domain-Name-Server Option 6, length 8: 192.168.2.1,142.166.166.166

Jeśli po uruchomieniu tej tcpdumpkomendy zobaczysz ofertę BOOTP / DHCP lub Ack (Nack), będzie ona pochodzić z serwera DHCP, a adres MAC serwera będzie znajdował się zaraz po znaczniku czasu w pierwszym wierszu.

Tak więc (prawidłowy) serwer DHCP ma tutaj adres MAC a8: 39: 44: 96: fa: b8`.

Używając jednego z wielu narzędzi do wyszukiwania adresów MAC w sieci , widzę, że ten MAC należy do A8:39:44 Actiontec Electronics, Incmojego routera.

Aby złapać nieuczciwe pakiety serwera DHCP, musiałbym pozostawić ten tcpdumpproces uruchomiony w oknie terminala:

tcpdump -i en0 -nev udp src port 67 and not ether host a8:39:44:96:fa:b8

To pokaże mi tylko odpowiedzi serwera DHCP od hostów innych niż mój prawidłowy serwer DHCP, o ile proces działa we własnym oknie.

Następujące polecenie będzie działać w tle, aż do przechwycenia 100 pakietów, dołączając do pliku wszelkie nieuczciwe komunikaty serwera DHCP /tmp/rogue. Ponownie adres MAC ważnego serwera DHCP musi zostać użyty w odpowiednim miejscu, a także deskryptor interfejsu w systemie.

tcpdump -U -i en0 -c 100 -nev udp src port 67 and not ether host a8:39:44:96:fa:b8 >> /tmp/rogue 2>&1 &

`

Nevin Williams
źródło
+1 używał tego przez cały czas w sieciach VoIP klienta, aby pomóc mu w wykrywaniu nieuczciwych serwerów DHCP, które popsuły jego usługę.
MaQleod
Tak, musiałem go używać do znajdowania nieuczciwych serwerów DHCP we wczesnych wdrożeniach sieci modemów kablowych, dopóki nie wymyśliliśmy, jak filtrować wychodzący port UDP 67 na każdym rodzaju modemów kablowych sprzed DOCSIS w naszej sieci. Nawet po tym, jak zidentyfikowaliśmy nieuczciwego, nie zawsze było możliwe określenie, za którym modem był. W ciężkich przypadkach musieliśmy wyłączyć każdy węzeł, aż łotrzyk się zatrzymał, a następnie wyizolować, jaki wzmacniacz w tym węźle zawęził liczbę rolek, które wykonałby MSO. Dobre czasy. Niech żyje DOCSIS.
Nevin Williams
wszelkie proste rozwiązanie, ponieważ chcę często sprawdzać za pomocą bash
Steve
Jeśli pozostawisz to tcpdumppolecenie uruchomione, wyświetli się pakiety serwera DHCP wysłane przez adres MAC inny niż adres serwera DHCP. Oczywiście musisz podać adres we wskazanym miejscu ... Umieszczę go obecnie w mojej odpowiedzi, aby uzyskać lepsze formatowanie.
Nevin Williams
0

Przy wystarczającej ilości czasu wykrycie pasywne może być możliwe: Przypomnij sobie, że klient inicjujący wysyła transmisję DHCPDISCOVER. Jeśli dostępny jest serwer dhcpserver, opuści on ofertę, a następnie wyemituje (ponownie jako transmisję!) ŻĄDANIE DHCP. A zatem

  • jeśli otrzymasz transmisję DHCPREQUEST, istnieje serwer dhcp
  • jeśli otrzymasz DHCPDISCOVER, ale w ciągu sekundy lub dwóch nie ma ŻĄDANIA DHCPREQUEST (aby uwzględnić zdalne serwery dhcp za pośrednictwem przekaźnika dhcp), nie ma serwera dhcp
  • jeśli nawet nie otrzymasz DHCPDISCOVER, musisz poczekać dłużej - lub spróbować aktywnie znaleźć serwer dhcp (np. zgodnie z metodą Kenneda)

Sukces pierwszych dwóch punktów zależy od liczby innych hostów nowo podłączonych / uruchomionych do sieci, a także od czasu dzierżawy.

Hagen von Eitzen
źródło
0

Możesz spróbować utworzyć urządzenie aliasowe i użyć klienta dhcp w trybie testowym, w którym wypisuje on dowolną odpowiedź bez faktycznej rekonfiguracji interfejsu:

ifconfig eth0:1 up
dhclient -w -n eth0:1

Mam tylko dostęp do skrzynki debian, więc jeśli masz inną implementację dhcp, opcja uruchamiania na sucho może być inna, jak w przypadku dhcpcd:

dhcpcd -T eth0:1

Kiedyś miałem skrypt crona uruchamiany z czymś takim, co ostrzegałoby administratora (mnie!) O nieuczciwych serwerach dhcp.

Kenned
źródło
1
kiedy zadzwoni ifconfig eth0:1 updo wyjściaSIOCSIFFLAGS: Cannot assign requested address
Steve