Überprüfen Sie mit bash, ob in meinem Netzwerk ein DHCP-Server vorhanden ist


23

Gibt es bei Verwendung von CentOS mit statischer IP-Adresse eine Möglichkeit, mithilfe von Bash festzustellen, ob ein DHCP-Server im Netzwerk ausgeführt wird?

Antworten:


44

nmap geht so einfach:

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

wird zeigen:

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

1
Obwohl die vorhandenen Antworten ziemlich gut waren, bevorzuge ich Ihre Lösung!
— Julie Pelletier

1
Guter Befehl, aber es ist erwähnenswert, dass dies nur den ersten DHCP-Server ausgibt, der antwortet. Wenn mehrere DHCP-Server vorhanden sind, werden sie mit diesem Befehl nicht gefunden.
— stochern

6

Falls im Repository verfügbar, gibt es dhcpdump

von der Manpage:

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.

5

Wenn Sie über tcpdumpdie folgenden Parameter verfügen , können Sie den Server leichter finden, indem Sie das Programm als root aufrufen:

tcpdump -i [Schnittstellen-ID] -nev udp Port 68

Leider kann ich aufgrund des Netzwerklayouts keinen vollständigen DHCP-Handshake sofort erfassen. Ich sehe jedoch eine DHCP-Anfrage von meinem iPad:

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"

Nachdem ich "tcpdump" über Nacht laufen ließ, sah ich schließlich diese 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

Wenn beim Ausführen dieses tcpdumpBefehls ein BOOTP / DHCP-Angebot oder eine Bestätigung (Nack) angezeigt wird, stammt dies von einem DHCP-Server, und die MAC-Adresse des Servers steht direkt nach dem Zeitstempel in der ersten Zeile.

Der (gültige) DHCP-Server hat hier also die MAC-Adresse a8: 39: 44: 96: fa: b8`.

Unter Verwendung eines der vielen MAC-Adressensuch-Tools im Web sehe ich, dass dieser MAC zu A8:39:44 Actiontec Electronics, Incmeinem Router gehört.

Um unerwünschte DHCP-Serverpakete aufzufangen, muss dieser tcpdumpProzess im Terminalfenster ausgeführt werden:

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

Dies zeigt mir nur DHCP-Serverantworten von anderen Hosts als meinem gültigen DHCP-Server an, solange der Prozess in einem eigenen Fenster ausgeführt wird.

Der folgende Befehl wird im Hintergrund ausgeführt, bis 100 Pakete erfasst wurden, und alle unerwünschten DHCP-Servermeldungen an die Datei angehängt /tmp/rogue. Auch hier muss die MAC-Adresse Ihres gültigen DHCP-Servers an der richtigen Stelle verwendet werden, sowie der Schnittstellendeskriptor auf Ihrem System.

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 &

`


+1 nutzte dies immer in den VoIP-Netzwerken der Kunden, um unerwünschte DHCP-Server ausfindig zu machen, die ihren Service in Mitleidenschaft gezogen haben.
— MaQleod

Ja, ich musste es verwenden, um unerwünschte DHCP-Server in frühen Bereitstellungen von Kabelmodem-Netzwerken zu finden, bis wir herausgefunden haben, wie der ausgehende UDP-Port 67 für jede Art von Pre-DOCSIS-Kabelmodems in unserem Netzwerk gefiltert werden kann. Selbst nachdem wir den Schurken identifiziert hatten, war es nicht immer möglich zu erkennen, hinter welchem ​​Modem er steckte. In schweren Fällen mussten wir jeden Knoten ausschalten, bis der Schurke aufhörte, und dann isolieren, welcher Verstärker auf diesem Knoten die Anzahl der LKW-Rollen einschränkte, die der MSO machen würde. Lustige Zeiten. Es lebe DOCSIS.
— Nevin Williams

jede einfache Lösung, weil ich häufig mit bash überprüfen möchte
— Steve

Wenn Sie diesen tcpdumpBefehl ausgeführt lassen, werden DHCP-Serverpakete angezeigt, die von einer MAC-Adresse gesendet werden, die sich von denen Ihres DHCP-Servers unterscheidet. Natürlich müssen Sie die Adresse an der angegebenen Stelle angeben ... Ich werde sie in meine Antwort einfügen, um eine bessere Formatierung zu erhalten.
— Nevin Williams

0

Wenn genügend Zeit zur Verfügung steht, kann die Erkennung möglicherweise passiv durchgeführt werden: Denken Sie daran, dass ein initialisierender Client eine DHCPDISCOVER-Übertragung sendet. Wenn ein DHCP-Server verfügbar ist, erhält er ein Angebot und sendet (erneut als Broadcast!) Eine DHCP-Anfrage. Somit

  • Wenn Sie eine DHCPREQUEST-Sendung empfangen, gibt es einen DHCP-Server
  • Wenn Sie DHCPDISCOVER, aber innerhalb von ein oder zwei Sekunden keine DHCPREQUEST erhalten (um entfernte DHCP-Server über DHCP-Relay zu berücksichtigen), gibt es keinen DHCP-Server
  • Wenn Sie nicht einmal DHCPDISCOVER erhalten, müssen Sie länger warten - oder versuchen, aktiv einen DHCP-Server zu finden (z. B. nach Kenneds Methode).

Der Erfolg der ersten beiden Punkte hängt von der Anzahl der anderen neu an das Netzwerk angeschlossenen / gebooteten Hosts sowie von den Lease-Zeiten ab.


0

Sie können versuchen, ein Alias-Gerät zu erstellen und einen DHCP-Client im Testmodus zu verwenden, der alle Antworten ausgibt, ohne die Schnittstelle neu zu konfigurieren:

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

Ich habe nur Zugriff auf eine Debian-Box. Wenn Sie also eine andere DHCP-Implementierung haben, könnte die Trockenlaufoption anders sein, wie bei dhcpcd:

dhcpcd -T eth0:1

Früher habe ich ein Cron-Skript mit so etwas ausgeführt, das den Administrator (mich!) Über nicht autorisierte DHCP-Server alarmierte.


1
wenn ifconfig eth0:1 updie Ausgabe aufrufenSIOCSIFFLAGS: Cannot assign requested address
— Steve
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.