DHCP über das WAN Interface und automatisch erzeugte Firewall-Regeln

[Patrick M. Hausen]

Der DHCP-Client schickt einen Request raus und erwartet eine Antwort. Wenn er nichts rausgeschickt hat, kannst Du ihn lange mit Paketen bewerfen, der tut damit nichts.

[MenschAergereDichNicht]

Ok. Danke.

Damit hätten wir das in epischer Breite geklärt 
(Ich meine den Thread als solchen. Nicht die letzte Antwort.)

[Jitterer]

Ich bin auch gerade dabei, mich in OPNsense einzuarbeiten und habe das gerade mal direkt getestet.
Die automatisch generierten Firewallregeln sehen bei mir so aus:


Und in der Tat sind die Ports per UDP 546, 547 offen und erreichbar über die IPv6 die der OPNsense zugewiesen sind... Komische Autogenerierung der Firewallregeln ... verstehe ich nicht, wieso eingehender Traffic automatisch an ist.

[Patrick M. Hausen]

Ohne diese Regeln funktioniert extern dein DHCPv6 nicht ...

[MenschAergereDichNicht]

> Ohne diese Regeln funktioniert extern dein DHCPv6 nicht

Das stimmt.

Prinzipiell ist es wohl so, dass DHCP "eigentlich" für das Intranet gedacht ist. Es ist schon etwas älter und hat die Sicherheit noch nicht so im Blick gehabt (der Wikipedia-Artikel hat eine nette Grafik zum Ablauf). Es gibt eine Lücke im Prozess ab dem Client-Broadcast bei dem sich böswillige DHCP-Server einbringen könnten.
Wenn man danach sucht, findet man auch verschiedene bekannte Attacken auf das Protokoll.
(Ich habe nur nach DHCP gesucht in der Annahme, dass DHCPv6 ähnlich funktioniert. Falls das erheblich sicherer sein sollte, nehme ich alles zurück :-) )

Eine denkbare Optimierung der Firewall wäre, dass die Ports dynamisch nach dem Client-Broadcast geöffnet und nach den Server-Antworten wieder geschlossen werden. Das würde erfolgreiche Port-Scans unwahrscheinlicher machen. Aber ich habe keine Ahnung, ob man das in den DHCP-Client eingebaut bekommt.

Letztendlich hoffe ich in meinem konkreten Fall, dass die Deutsche Glasfaser so etwas weiß, wenn sie das Protokoll verwendet, um ihre Kunden anzubinden und dementsprechend in ihrem Netz den Verkehr von außerhalb auf diese UDP-Ports unterbindet.
(TODO für mich: ich werde das testen, wenn ich angeschlossen bin)

[JeGr]

> Eine denkbare Optimierung der Firewall wäre, dass die Ports dynamisch nach dem Client-Broadcast geöffnet und nach den Server-Antworten wieder geschlossen werden. Das würde erfolgreiche Port-Scans unwahrscheinlicher machen. Aber ich habe keine Ahnung, ob man das in den DHCP-Client eingebaut bekommt.

Das lässt sich so gar nicht umsetzen. Nach Ablauf der DHCP Lease Time wird das Lease per DHCP erneuert. Dann müssten die Regeln wieder aktiv sein - bzw. vorher schon. Da die Lease Time aber vom DHCP SERVER bestimmt wird und nicht von dir auf der Client Seite, kannst du dich ohne weiteres gar nicht drauf einstellen, wann welche Regel an und abgeklemmt werden muss. Klar kann man alles irgendwie versuchen zu programmieren, aber bei DHCP hier jetzt anzusetzen ist das Problem IMHO out of scope.

Zumal auch @Jitterer übersieht, dass DHCP immer NUR im aktuellen Netzsegment arbeitet da Broadcasts nicht ohne weiteres geroutet werden. Welcher Angreifer soll also per DHCP euch als Client einen falschen Server unterschieben? Der müsste dann ja genau in dem Netzabschnitt zu eurem ISP sitzen. Also entweder ein anderer Kunde der zufällig im gleichen Abschnitt ist (was wechseln kann) oder der ISP selbst. Und damit wäre - rein theoretisch der ISP kompromittiert. Das ist nun wirklich nicht unbedingt der Scope der Firewall sich dagegen ggf. zu schützen, wenn der Anschluß selbst das Problem ist. DHCP4 bzw DHCP6 entsprechend zuzulassen und von wo ist eben Handwerkszeug und Job des ISPs

[MenschAergereDichNicht]

> DHCP4 bzw DHCP6 entsprechend zuzulassen und von wo ist eben Handwerkszeug und Job des ISPs

Vermutlich ist das so.

Zur Erklärung meines Gedankenganges:

Ein Angreifer müsste sich ja nur im aktuellen Netzwerksegment befinden, wenn er direkt auf einen Broadcast antworten würde.
Er könnte doch auch "einfach" von irgendwo meine öffentliche IPv6-Adresse mit UDP DHCP-Server Antworten "bombardieren", bis mein DHCP-Client ein neues Lease benötigt, oder? Das könnte zugegebenermaßen etwas dauern, wäre aber eine Möglichkeit.
Ich gebe zu, dass es vermutlich eher theoretisch ist. Ich wollte nur darauf hinaus, dass DHCP per se offenbar kein sicheres Protokoll ist. Und ja, vermutlich wird das beim ISP irgendwo (hoffentlich) unterbunden.

[MenschAergereDichNicht]

> Da die Lease Time aber vom DHCP SERVER bestimmt wird und nicht von dir auf der Client Seite, kannst du dich ohne weiteres gar nicht drauf einstellen, wann welche Regel an und abgeklemmt werden muss

Ich dachte, dass die Kommunikation immer vom Client ausgeht.
D.h. der Client prüft den Ablauf und nimmt dann Kontakt zum Server auf.
Wenn das so ist, sollte man es ja (theoretisch) dynamisch freischalten können.

Was ich bisher nicht gesehen habe, ist, dass der Client wohl nach Ablauf des Lease zuerst versucht Kontakt zum bisherigen Server aufzunehmen. Ich habe gedacht, dass er dann direkt wieder Broadcasts verschickt. Das ist offenbar nur der Fall, wenn der bisherige Server nicht antwortet.

D.h. wenn der bisherige DHCP-Server "sticky" ist und typischerweise nur bei der ersten Kontaktaufnahme der Broadcast-Modus aktiv ist, sollte das tatsächlich relativ unkritisch sein.

Sorry für den langen Rant. Aber ich versuche das wirklich zu verstehen.

[MenschAergereDichNicht]

*Ursprünglich* ging es hier ja darum, dass ich dachte, ich würde über DHCP an das Netzt angebunden werden.
Die Vermutung kam daher, dass mein Provider das Netz der Deutschen Glasfaser verwendet.

Heute bin ich tatsächlich angeschlossen worden und habe festgestellt, dass die Einwahl über PPPoE läuft... .

Falls es jemanden interessiert. Der Provider ist HTP und man muss die VLAN-ID 22 verwenden. Hat auch sofort alles funktioniert.

[JeGr]

> PPPoE ...
Schade. Wieder mal ein Glas Anbieter der alten Murks einsetzt statt den Kram endlich wegzuwerfen.

Aber immerhin fein, dass es gleich geklappt hat.