Hallo,
ich versuche gerade zu verstehen, ob ich einen Denkfehler bei der DHCP-Anbindung des WAN-Interfaces habe.
Demnächst bekomme ich einen Glasfaseranschluss von der "Deutschen Glasfaser". Wenn ich das richtig verstanden habe, erfolgt die Anbindung auf meiner Seite über DHCPv6. D.h. ich würde gerne anstelle z.B. einer Fritzbox eine APU mit OPNSense als Router verwenden.
Bei meiner aktuellen Konfiguration (DSL) befindet sich die APU *hinter* der Fritzbox. Wenn ich mir dort die automatisch angelegten Regeln des WAN-Interfaces anschaue, sehe ich, dass die Firewall für DHCP generell durchgängig ist. Das ist in dieser Konfiguration (Firewall hinter Fritzbox) auch kein Problem. Wenn allerdings nach der Umstellung auf Glasfaser die Fritzbox wegfällt und die OPNSense direkt am Provider-WAN hängt, würde ich eigentlich nicht so gerne den Netzwerkverkehr von jedermann in diese UDP -Ports reinlassen.
Übersehe ich irgendetwas Offensichtliches? Wird DHCP-Traffic bereits durch den Provider gefiltert?
Danke im Voraus.
ich habe ja keine ahnung welchen tarif du bei deinem provider gebucht hast, ist es mehr als 100mbit/s ersetze lieber die apu mit was mehr leistung hat.
anregung findest du genug hier im forum.
meine empfehlung entweder die original opnsense hardware kisten oder schau dir die systeme bei nrg-systems an (IPU8xx)
Gesendet von iPad mit Tapatalk Pro
Mir geht es erstmal weniger um den Durchsatz als vielmehr um den Sicherheits-Aspekt.
Das oben beschriebene Problem(?) gibt es ja auch bei einem schnelleren Router.
Wenn ich merke, dass die APU (die ich bereits besitze) mit den 250 Mbit nicht zurecht kommt, schaue ich mich weiter um.
DHCP ist generell nicht routebar, d.h. ohne ein spezielles Relay kommt das gar nie nicht über Interfaces hinweg, selbst wenn alle Regeln auf "offen" stehen sollten.
Und Deine Firewall wird Deinen Provider mit DHCP-Anfragen bewerfen, die dieser beantwortet. Da kommt garantiert kein DHCP aus dem Internet bis vor Deine Tür.
Grüße
Patrick
Super. Danke für die Antwort. Ich habe mir schon gedacht, dass ich irgendwo einen Denkfehler habe.
wenn du im forum mal nach deutsche glasfaser gesucht hättest währst du bestimmt auf weitere hinweise gestoßen wie andere user ihr wan interface konfiguriert haben/hatten
Gesendet von iPad mit Tapatalk Pro
Das habe ich natürlich gemacht.
Das Problem ist/war ja nicht, es überhaupt in Betrieb zu nehmen, sondern der Sicherheits-Aspekt der offenen Ports durch die automatischen Regeln.
Aber das hat sich, wie oben bereits erwähnt, jetzt geklärt.
> Aber das hat sich, wie oben bereits erwähnt, jetzt geklärt.
Um das genauer zu sagen - weil es ja keine Frage nach WAN war wie Mic fälschlich angenommen hat: DHCP Anfragen gehen grundsätzlich als Broadcast (255.255.255.255) an udp 67/68 raus. Aus der Tatsache Broadcast ergibt sich dann was Patrick schon gesagt hat: das klappt rein technisch ohne weitere Maßnahmen schon nicht über Netzgrenzen hinaus, da ein Broadcast nicht einfach weitergeroutet wird.
Generell ist es aber wenn die *sense direkt am WAN steht bzw. direkt die externe IP trägt keine allzu schlechte Idee ;) wenn man bestimmte Ports/Protokolle und IPs ausgehend am WAN blockt. Sowas wie tcp/udp 135-139/445 und generell IP4s vom Typ RFC1918 (also alle privaten Adressen) abgehend zu filtern wäre keine schlechte Idee. Die Richtlinien fürs Routing sagen zwar, dass der Provider am nächsten Hop die eh verwerfen muss - aber man möchte da ja auch oft keine Daten preisgeben die durch bspw. falsches Routing oder einen temporären Konfig-Fehler aufgetreten sind. Und sowas ausgehend am WAN zu blocken war seit ISDN Zeiten schon nie ne schlechte Idee ;)
Cheers
\jens
Eigentlich habe ich dabei bisher nur an den eingehenden Traffic gedacht.
Aber stimmt schon. Vermutlich sollte ich ich da etwas nachschärfen. Zumindest dann, wenn ich "block private networks" nicht verwenden kann.
Was ich nicht verstehe, die Deutsche Glasfaser DG stellt Dir doch einen Router zur Verfügung, d.h. zunächst einmal hängt Opnsese überhaupt nicht direkt am WAN. die DHCP-Anfrage für IPv6 geht damit an den Router, welcher opnsense eine öffentliche IPv6 (GUA) zur Verfügung stellt. In der "Grundkonfiguration" ist damit bezüglich Traffic von außen an dem Router von DG schluss. Ich würde das erst mal in diesem Setup probieren, damit sollte erst mal alles funktionieren. Wenn Du Dich dann mit opnsense etwas besser auskennst, kannst später Du immer noch die Opnsese als exposed host den Router hängen und dich entsprechend mit eingehenden Regeln beschäftigen. Aber auch da gilt, alles was nicht explizit von außen erlaubt ist, wird geblockt. Und wie bereits zuvor erwähnt wurde, die automatischen Regeln für DHCP auf dem WAN Interface sind kein Problem, weil DHCP nicht geroutet wird.
Ich bin nicht direkt bei der Deutschen Glasfaser sondern über einen "Mittelsmann"(HTP) der deren Netz verwendet.
Aber auch dort gibt es natürlich einen Router dazu, wenn man möchte.
Da ich nach Möglichkeit nicht unnötig viele Geräte hier in Betrieb haben will und das Netz der Deutschen Glasfaser per DHCPv6 angebunden ist (am Medienkonverter), ist es relativ nahe liegend auf den Router zu verzichten.
Die Konfiguration mit einer Fritzbox vor der OpnSense habe ich aktuell bei meinem DSL-Anschluss. Das ginge natürlich weiterhin. Da ich die Fritzbox aber nur als Modem verwende (kein DECT-Telefon,...), wäre das bei dem Glasfaser-Setup eigentlich überflüssig.
> Aber stimmt schon. Vermutlich sollte ich ich da etwas nachschärfen. Zumindest dann, wenn ich "block private networks" nicht verwenden kann.
Das blockt nur EINgehenden Traffic auf dem WAN, nicht ausgehenden.
Ausgehend RFC1918 zu blocken ist aber nie verkehrt. Es gibt praktisch kaum einen (keinen?) effektiven Fall bei dem man das aktiv haben möchte, dass privater Traffic ins Internet rausblubbert. Gesetzt den Fall natürlich, dass man ein normales WAN/Internet hat und keine spezielle Konstruktion oder vorgeschaltete Systeme etc. das ist selbstredend klar.
Cheers
Danke für die Info.
Dann müsste ich jetzt eigentlich alles zusammen gesammelt haben, was ich brauche. Mein Anschlusstermin ist der 01.12. . Mal schauen, ob es klappt.
Daumen sind gedrückt
Da ich das hier versammelte Wissen unbedingt ausnutzen muss :-), habe ich noch eine Anschlussfrage.
Das "normale" Verhalten im DHCP-Fall habe ich, denke ich zumindest, jetzt verstanden.
Wie ist es aber, wenn ein potentieller Angreifer auf meiner öffentlichen IPv6-Adresse einen Port-Scan macht, herausfindet, dass die UDP-Ports 67/68 erreichbar sind und mir dann "böswilligen" Traffic dahin schickt?
Ich gehe davon aus, dass der DHCP-Client Traffic von einer nicht aus der Broadcast-Domäne stammenden Adresse abweist. Ist das so? Gleichfalls gehe ich davon aus, dass ungefragter Traffic, d.h. ohne vorherige Anfrage, verworfen wird. Ist das so?
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.
Ok. Danke.
Damit hätten wir das in epischer Breite geklärt :)
(Ich meine den Thread als solchen. Nicht die letzte Antwort.)
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:
(https://i.ibb.co/CBK54sX/image.png) (https://ibb.co/8MgDG4R)
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.
Ohne diese Regeln funktioniert extern dein DHCPv6 nicht ...
> 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)
> 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 :)
> 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.
> 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.
*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.
> PPPoE ...
Schade. Wieder mal ein Glas Anbieter der alten Murks einsetzt statt den Kram endlich wegzuwerfen.
Aber immerhin fein, dass es gleich geklappt hat.