DHCP-Starvation 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.)