dhcpcd, potentielle Gefahrenquelle? Fragen zu DHCP

[andreask2]

Hallo!

Ich habe mein Gentoo für DHCP konfiguriert, weil ich das am bequemsten fand, und keine Nachteile sah. Allerdings hat das folgende Kosequenz:

Code: Select all

# netstat -anu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp   106080      0 0.0.0.0:68              0.0.0.0:*

Code: Select all

# lsof -P -n -i UDP:68
COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
dhcpcd  24795 root    4u  IPv4 108257       UDP *:68

Code: Select all

# dhcpcd --help
DHCP Client Daemon...

Es ist also kein DHCP-Server, wie ich hier im Forum irgendwo gelesen hatte ;-)

Wieso überhaupt "Daemon"? Reicht es nicht beim Starten einmalig die Netzwerkeinstellungen vorzunehmen? Wozu muss danach noch ständig ein Prozess laufen, der an einem Socket auf Anweisungen wartet?

Ich vermute mal, das DHCP-Protokoll sieht Möglichkeiten vor, während des Betriebs etwas an den Einstellungen ändern zu können. Naja, ist aber bei einem root-server wohl sehr unwahrscheinlich, bringt als nichts.

Natürlich will ich grundsätzlich vermeiden dass ein unnötiger Dienst über das Netzwerk erreichbar ist, wobei ich langsam glaube ich werde etwas paranoid ;-)

Naja, jedenfalls habe ich mir mal was zu DHCP duchgelesen, aber so 100% blicke ich noch nicht durch. Wie ich das verstanden habe, verwendet DHCP das BOOTP Protokoll, wenn ein Client per DHCP eine Adresse anfordert, schickt er per Broadcast einen Requst an die IP 255.255.255.255, Port 67, so dass der Switch diese Anfrage an jeden Rechner im Netzwerk weiterleitet, und ein DHCP-Server diese dann empfängt und eine entspechende Antwort mit IP-Adress-Vorschlag an diese Mac-Adresse schickt (an 0.0.0.0 geht ja nicht, es könnten ja gleichzeitig mehrere Rechner eine IP anfordern, oder?). Wobei die Antwort ja eigentlich über UDP kommen müsste, also doch an 0.0.0.0? Aber was ist dann mit mehrere Anfragen die Gleichzeitig kommen?

Besteht keine Gefahr dass irgendwie in diese Kommunikation eingegriffen wird, oder das von einem anderen, "bösen" Server eine falsche Antwort kommt? Und wenn der "Client-Daemon" dann ständig auf Anfragen wartet, wie wird sichergestellt dass da nicht ein böser Server versucht die IP-Adresse oder Gateway-Adresse des Clients zu verändern, und ihn somit quasi vom Netz zu trennen?

Grüße
Andreas

[captaincrunch]

Zunächst mal musste ich dazu direkt mal an http://www.isc.org/index.pl?/sw/dhcp/dhcp_rel.php denken:

# CAN-2004-0460 - CERT VU#317350: Five stack overflow exploits were closed in logging messages with excessively long hostnames provided by the clients. It is highly probable that these could have been used by attackers to gain arbitrary root access on systems using ISC DHCP 3.0.1 release candidates 12 or 13. Special thanks to Gregory Duchemin for both finding and solving the problem.
# CAN-2004-0461 - CERT VU#654390: Once the above was closed, an opening in log_*() functions was evidented, on some specific platforms where vsnprintf() was not believed to be available and calls were wrapped to sprintf() instead. Again, credit goes to Gregory Duchemin for finding the problem. Calls to snprintf() are now linked to a distribution-local snprintf implementation, only in those cases where the architecture is not known to provide one (see includes/cf/[arch].h). If you experience linking problems with snprintf/vsnprintf or 'isc_print_' functions, this is where to look. This vulnerability did not exist in any previously published version of ISC DHCP.

;)

Wieso überhaupt "Daemon"? Reicht es nicht beim Starten einmalig die Netzwerkeinstellungen vorzunehmen?

Ja, reicht es. Daher wird das auch genau so in meinem Debian-Installer gehandhabt.

Ich vermute mal, das DHCP-Protokoll sieht Möglichkeiten vor, während des Betriebs etwas an den Einstellungen ändern zu können. Naja, ist aber bei einem root-server wohl sehr unwahrscheinlich, bringt als nichts.

Haargenau. Ich selbst hätte es jedenfalls innerhalb der letzten fast zwei Jahren nicht mitbekommen, dass da irgendw etwas geändert wurde.

Wie ich das verstanden habe, verwendet DHCP das BOOTP Protokoll,

Nein, DHCP ist ein eigenes Protokoll (genauer gesagt eine Weiterentwicklung von BOOTP).

Besteht keine Gefahr dass irgendwie in diese Kommunikation eingegriffen wird, oder das von einem anderen, "bösen" Server eine falsche Antwort kommt?

Die prinzipielle Gefahr besteht auf jeden Fall, so lange du nicht sicherstellen kannst, dass die erhaltene IP auch wirklich von dem DHCP-Server kommt, von dem aus sie kommen sollte. Antwortet (aus welchem Grund auch immer) ein anderer zuerst, besteht die Möglichkeit, dass du eine falsche IP bekommst.
OK, zugegeben, 2&4 wird dahingehend mit großer Wahrscheilichkeit Schutzmaßnahmen ergiffen haben, ich persönlich schlafe durch das manuelle Setup aber irgendwie trotzdem besser. ;)

[andreask2]

Dann werde ich wohl auch auf auf statische Adresse umsteigen ;-)

Aber jetzt habe ich mich wenigstens mal mit DHCP beschäftigt und noch ein bisschen im RFC nachgelesen... und weiß womit man ein Betriebssystem über das Netzwerk bootet ;)

[dodolin]

Wieso überhaupt "Daemon"? Reicht es nicht beim Starten einmalig die Netzwerkeinstellungen vorzunehmen?

Ja, reicht es. Daher wird das auch genau so in meinem Debian-Installer gehandhabt.

Das ist so nicht korrekt.

Wenn man DHCP verwenden möchte, braucht man sehr wohl einen Dämon, weil eine per DHCP erhaltene IP z.B. eine Lease-Time hat und danach vom Client erneuert werden muss.

Dass man auch auf DHCP komplett verzichten kann, stimmt allerdings. :)

Besteht keine Gefahr dass irgendwie in diese Kommunikation eingegriffen wird, oder das von einem anderen, "bösen" Server eine falsche Antwort kommt?

Die prinzipielle Gefahr besteht auf jeden Fall, so lange du nicht sicherstellen kannst, dass die erhaltene IP auch wirklich von dem DHCP-Server kommt, von dem aus sie kommen sollte.

Nicht nur das. Der Client hat ja auch gar keine Möglichkeit zu wissen, wer denn jetzt der "echte" DHCP Server ist. Deshalb muss er ja auch an die Broadcast Adresse senden. Wer zuerst antwortet, hat gewonnen.

Ich würde allerdings davon ausgehen, dass die Broadcasts sowieso nur bei den DHCP Servern vom Provider landen, da er ja eine Netzwerkmaske von /32 fährt... ;) Man sieht, diese Netzmaske hat durchaus Vorteile, nämlich, z.b. dass die Kundenserver besser voneinander abgeschottet sind.

[andreask2]

Wenn man DHCP verwenden möchte, braucht man sehr wohl einen Dämon, weil eine per DHCP erhaltene IP z.B. eine Lease-Time hat und danach vom Client erneuert werden muss.

Aber wozu muss der Cient dann ständig ein Socket aufhaben? Er könnte das doch aufbauen, wenn er sich beim Server melden will, oder? Kann der Server denn über DHCP auch während des Betriebs z.B. die Gateway-Adresse ändern? Wobei das ja auch nicht die Gefahr wäre, denn der Client kennt ja die IP des Servers, wobei ein Angreifer natürlich per ARP-Spoofing möglicherweise auch eine Antwort um einen Befehl zu verifizieren vom Client abfangen könnte, so theoetisch ;-)

Das CC das "nicht-verwenden" von DHCP meinte war mir übrigens trotzden klar, zumal ich mir während meine Gentoo-Installation den Installer etwas genauer angesehen habe ;-)

Die prinzipielle Gefahr besteht auf jeden Fall, so lange du nicht sicherstellen kannst, dass die erhaltene IP auch wirklich von dem DHCP-Server kommt, von dem aus sie kommen sollte.

Nicht nur das. Der Client hat ja auch gar keine Möglichkeit zu wissen, wer denn jetzt der "echte" DHCP Server ist. Deshalb muss er ja auch an die Broadcast Adresse senden. Wer zuerst antwortet, hat gewonnen.

Ich würde allerdings davon ausgehen, dass die Broadcasts sowieso nur bei den DHCP Servern vom Provider landen, da er ja eine Netzwerkmaske von /32 fährt... ;) Man sieht, diese Netzmaske hat durchaus Vorteile, nämlich, z.b. dass die Kundenserver besser voneinander abgeschottet sind.

Aber ich dachte das funktioniert auch mit 24er Netzmaske? Natürlich würde ich das nicht machen, aber mich wundert etwas dass es auch parallel mit 32 und 24 funktioniert.

Naja, ich denke der kritische Punkt ist, wenn der Client auf die Antwort irgendeines Servers wartet, wenn die das dann so konfiguriert haben, dass normale Server diese broadcast Pakete erst gar nicht bekommen (womit würde man sowas sicherstellen - einem managed Switch?), dann müsste ein Server wahllos broadcast-pakete an 0.0.0.0 senden, wo es dann sehr unwahrscheinlich ist dass sowas nicht auffällt, und dass er überhaupt erster ist, denn da müsste er ja auf die Millisekunde genau im richtigen Moment gesendet haben. Abgesehen davon würden die dann diese Pakete so oder so filtern, oder?

Bleibt noch das Problem mit ARP-Spoofing - obwohl, vermutlich werden die Filter in so einem Switch dann eh anhand der MAC-Adresse festgelegt, oder? Und evtl. sind die enntsprechenden Server auch fest eingetragen.

Naja, ich bewege mich wohl ein bisschen weit weg vom Thema ;-)

[dodolin]

Aber wozu muss der Cient dann ständig ein Socket aufhaben?

Gute Frage, nächste Frage. Ist vermutlich in der Tat überflüssig. Aber so genau kenne ich das DHCP Protokoll nun auch wieder nicht. Wie wäre es z.B., mal den Traffic von diesem Dämon per tcpdump o.ä. mitzuloggen, dann weißt du, ob bzw. wofür das nötig ist.

Kann der Server denn über DHCP auch während des Betriebs z.B. die Gateway-Adresse ändern?

Nope. Bzw. nur dann, wenn ein neuer Lease fällig wird.

Wenn man während des Betriebs den Gateway ändern müsste, würde man das für gewöhnlich mit ICMP Redirects machen.

Aber ich dachte das funktioniert auch mit 24er Netzmaske?

Ja. Weil das ganze über den Switch gemanaged wird und dieser vermutlich entsprechend konfiguriert ist.

dass normale Server diese broadcast Pakete erst gar nicht bekommen (womit würde man sowas sicherstellen - einem managed Switch?),

Ja, z.B.

dann müsste ein Server wahllos broadcast-pakete an 0.0.0.0 senden, wo es dann sehr unwahrscheinlich ist dass sowas nicht auffällt, und dass er überhaupt erster ist, denn da müsste er ja auf die Millisekunde genau im richtigen Moment gesendet haben. Abgesehen davon würden die dann diese Pakete so oder so filtern, oder?

Du meinst nicht "Server", sondern "Angreifer", das hat mich etwas verwirrt. Ja, sowas wird der ISP sicher filtern, sofern er etwas Clue hat.

Bleibt noch das Problem mit ARP-Spoofing - obwohl, vermutlich werden die Filter in so einem Switch dann eh anhand der MAC-Adresse festgelegt, oder? Und evtl. sind die enntsprechenden Server auch fest eingetragen.

Versuch doch mal, auf einem 1&1 Rootserver deine MAC zu spoofen! Sag aber hinterher nicht, ich hätte dich nicht gewarnt! ;) Alternativ: Lese hier im Forum mal rum, die Switches drehen solchen Kisten sofort komplett den Saft ab...

[andreask2]

Bleibt noch das Problem mit ARP-Spoofing - obwohl, vermutlich werden die Filter in so einem Switch dann eh anhand der MAC-Adresse festgelegt, oder? Und evtl. sind die enntsprechenden Server auch fest eingetragen.

Versuch doch mal, auf einem 1&1 Rootserver deine MAC zu spoofen! Sag aber hinterher nicht, ich hätte dich nicht gewarnt! ;)

Es ist doch erst einige Wochen/Monate her, wo verschiedene Magazine bei diversen Hostern hier Defizite festgestellt haben. Beruhigend dass 1und1 hier vernünftig konfiguriert hat.

Und ich hatte auch nicht vor so eine Aktion zu starten, und ich wollte auch nicht meinen Nachbarn im RZ mit einer neuen Gateway-Adresse ausstatten ;-), aber mich interessiert, was man mit DHCP theoretisch anrichten könnte. Was ich sicher weiß ist dass ich auf einem Root-Server kein DHCP mehr verwende, auch wenn da alles mögliche gefiltert wird - Nervenkitzel hole ich mir trotzdem lieber woanders :)

Alternativ: Lese hier im Forum mal rum, die Switches drehen solchen Kisten sofort komplett den Saft ab...

Würde ich sehr gerne lesen, aber irgendwie verwende ich wohl die falschen Suchbegriffe.


PS: http://faq.1und1.de/server/windows/security/9.html
PPS: [OT] http://faq.1und1.de/server/root_server/security/2.html (siehe an, siehe an... ;-))

[dodolin]

aber mich interessiert, was man mit DHCP theoretisch anrichten könnte

In einem normalen, gehub'ten Netzwerk (oder in einem geswitchten, wenn der Switch z.B. durch Floods in den Hub-Modus wechseln muss), dürfte die Chance recht groß sein, dass jemand, der sich lokal an Port 69 (?) binden kann (also Administrator bzw. Rootrechte hat), DHCP Server zumindest für dieses Netzsegment spielen kann.

Würde ich sehr gerne lesen, aber irgendwie verwende ich wohl die falschen Suchbegriffe.

Ohne das jetzt zu testen, ich würde es mal mit: "server+gesperrt" versuchen.

[andreask2]

Naja, ich find nix :)

Aber in diesem Zusammenhang, ich hatte mal mit dem Gedanken gespielt, einen 2. Root-Server zu mieten, und per heartbeat, bzw. per "Gratuitous ARP" im Falle eines Ausfalls des Live-Servers, den Backup-Server die IP annehmen zu lassen, aber das kann ich wohl vergessen wenn ich mir das so recht überlege, was?

[captaincrunch]

Sofern du die Kisten bei 2&4 stehen hast auf jeden Fall. ;)

[andreask2]

Naja, wenn es denn der Sicherheit dient...

Früher oder später ist eh geplant eigene, bzw. geleaste Server housen zu lassen, und ich kläre gerade eh ab ob ich bei den "Europa Hostern" ;-) evtl. auch später einen eigenen Server neben einen gemieteten dedizierten Server in ein Subnetz stellen kann...