Diskussion:DHCP Starvation Attack

Immer noch Qualitätsmängel

Hi Jpp, aus meiner Sicht ist weder die Frage geklärt, ob dieser Artikel wirklich aus Dynamic Host Configuration Protocol ausgegliedert werden muss, noch das Entfernen des QS-Bapperl wirklich gerechtfertigt.

Ad 1) - Du hattest die Auslagerung mit der Einordnung in Kategorie:Sicherheitslücke gerechtfertigt. Das kann ich nicht nachvollziehen. Zum einen ist es keine Sicherheitslücke, wenn DHCP innerhalb der Specification von RFC 2131 verwendet wird. Das geschilderte Szenario ist dort im Abschnitt 7. Security Considerations beschrieben - übrigens mit erheblich weniger Worten als dieser Artikel braucht: „ Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.“. Die Sicherheitslücke ist also der malicious client in einem geschützten Netz. Die Firma, die einen solchen Client im Netz hat, hat wirklich ein Problem.

Ad 2) - Der Artikel lässt essentielle Informationen aus - und erweckt so den Eindruck als ob diese Attacke eine generelles Problem darstellt und die Funktion des Server vollständig blockieren könnte:

• Kein Hinweis darauf, dass dynamisch vergebene Adressen nur einen Teildienst darstellen und fest reservertierte Addressbereiche von dieser Attacke nicht berührt werden.
• Kein Hinweis darauf, dass für bereits registrierte Clients immer noch die Konfigurations-Daten geliefert werden, auch wenn die Vergabe neuer Adressen erschöft ist.
• Kein Hinweis auf das Exhaust-Verhalten des Servers, der die Möglichkeit hat, nicht mehr antwortende Clients zu deregistrieren.
• Kein Hinweis darauf, dass DHCP praktisch immer in geschlossenen Netzen verwendet wird und deshalb ein Angriff von aussen effektiv durch eine Firewall verhindert wird.
• Kein Hinweis auf den in mehrfacher Hinsicht aussergewöhlichen Fall, dass ein solcher Angriff aus dem eigenen Netz erfolgen muss und den Zusammenhang mit Schadprogrammen auf den angeschlossenen Workstations.
• Der Abschnitt Gegenmassnahmen ist schlicht unverständlich - der referenzierte Artikel Port Security ist ebenfalls ein Fall für die QS.

Fazit - der Leser ohne Vorkenntnisse wird durch diesen Artikel eher irregeführt, kein Hinweis auf Literatur oder die zugrundeliegende RFCs, kein Beleg für die Behauptung, beim Design des Protokolls wäre davon ausgegangen worden, dass jeder Client nur eine Hardware-Adresse verwendet, sprachliche Unzulänglichkeiten. --00:35, 18. Okt. 2008 (CEST)

Sei mutig und ergänze den Text. --j ?! 20:28, 19. Okt. 2008 (CEST)

Habe die wesentlichen Kritikpunkte mal im Artikel verarbeitet. Bitte ggf. sprachlich korrigieren. Kann der Baustein jetzt raus?--62.224.162.238 21:28, 8. Dez. 2010 (CET)

DHCP innerhalb eines Subnets oder innerhalb einer Broadcast-Domäne?

Hallo Zusammen

Ich habe soeben im Satz "Die Störwirkung einer DHCP Starvation Attack ist begrenzt auf ein Subnetz..." das Wort Subnetz mit Broadcast-Domäne ersetzt. Nach meinem Verständnis sind DHCP Nachrichten nicht auf ein Subnetz beschränkt, sondern könnte mittels eines DHCP-Relays-Agents auch in ein anderes Netzwerk weitergeleitet werden. Bitte korrigiert mich, falls ich falsch liegen sollte. --Phileceed (Diskussion) 09:46, 11. Jun. 2014 (CEST)

Leitet ein DHCP-Relay-Agent die DHCP-Anfragen nicht gerade zwischen mehreren Broadcast-Domänen (und nicht Subnetzen) weiter? --195.137.217.234 09:10, 17. Okt. 2014 (CEST)