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

Started by MenschAergereDichNicht, November 12, 2021, 04:33:05 PM

Previous topic - Next topic
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
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser  |
Router/Firewall: pfSense+ 23.09  |
Hardware: Netgate 6100

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
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

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
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser  |
Router/Firewall: pfSense+ 23.09  |
Hardware: Netgate 6100

November 12, 2021, 05:31:21 PM #6 Last Edit: November 12, 2021, 05:36:08 PM by MenschAergereDichNicht
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
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

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
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

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
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

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?