17
DMZ mit OPNsense, Firewallregeln?
Hallo zusammen,
habe meine OPNsense FW installiert und die Interfaces zugewiesen (WAN, DMZ, LAN), nun geht es an die Erstellung der FW Regeln was für mich Neuland ist und es einiges zu lernen gibt.
Um mich mit OPNsense vertraut zu machen habe ich mein Netzwerk in VirtualBox nachgebildet, der Netzwerkaufbau sieht folgendermaßen aus (falls ich relevante Informationen im Bild vergessen habe bitte ich um einen Hinweis)
Ich habe bisher folgende Firewall Regeln erstellt:
DMZ:
LAN:
VG Pete
habe meine OPNsense FW installiert und die Interfaces zugewiesen (WAN, DMZ, LAN), nun geht es an die Erstellung der FW Regeln was für mich Neuland ist und es einiges zu lernen gibt.
Um mich mit OPNsense vertraut zu machen habe ich mein Netzwerk in VirtualBox nachgebildet, der Netzwerkaufbau sieht folgendermaßen aus (falls ich relevante Informationen im Bild vergessen habe bitte ich um einen Hinweis)
Ich habe bisher folgende Firewall Regeln erstellt:
DMZ:
LAN:
VG Pete
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1445157905
Url: https://administrator.de/contentid/1445157905
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
17 Kommentare
Neuester Kommentar
Moin,
die Frage ist: Was willst du denn erreichen mit deinen Regeln?
Gruß Kümmel
die Frage ist: Was willst du denn erreichen mit deinen Regeln?
Gruß Kümmel
Irgendwie wurde mein Beitrag schon veröffentlicht obwohl ich noch nicht fertig war, hab wohl den falschen Knopf erwischt und bearbeiten kann ich nicht - die Änderungen wären zu umfangreich.
Dann stelle ich meine Fragen gesondert:
VG Pete
Dann stelle ich meine Fragen gesondert:
- Mein Ziel ist es die DMZ soweit wie möglich zum Internet hin abzuschotten (Motto: "Nur soviel wie nötig, so wenig wie möglich")
- Nethserver muss in der Lage sein Updates zu ziehen, wobei ich bisher nicht herausfinden konnte welche Ports dafür genutzt werden, ich vermute 80 (HTTP) und/oder 443 (HTTPS)
- Nextcloud soll sowohl vom Internet als auch vom LAN aus erreichbar sein
- Der SMB Fileserver soll nur aus dem LAN errreichbar sein.
- Das LAN soll soweit wie "praktikabel" geschützt sein, so dass ich nicht ständig Regeln hinzufügen muss. Ich denke "allow any" bildet das Verhalten eines üblichen Consumer Routers ab und ist erstmal eine praktikable Einstellung?
VG Pete
Moin,
Kein Problem. Eine Firewall arbeitet grundsätzlich nach einer Whitelist, d.h. es wird alles geblockt was du nicht explizit freischaltest.
Die Distribution Nethserver nutzt YUM als Paketmanager, also ja, es wird eine HTTP Freigabe benötigt.
Na dann einfach die Regeln setzen...
Nein, dann wäre ja die Firewall wieder überflüssig....Eine allow any Freigabe ist immer schwachsinn und sollte höchstens nur zum testen verwendet werden. Wer Sicherheit möchte, muss auch etwas Bequemlichkeit aufgeben. Zumal du ganz sicher nicht ständig Änderungen an deinem Regelwerk durchführen musst, besonders weil das ganz sicher doch nur ein privates Projekt in deinem Heimnetz ist, oder?
Übrigens haben die meisten Endkunden nur ein Router und benötigen keine DMZ, daher kommt vielleicht deine Einschätzung.
MfG
Mein Ziel ist es die DMZ soweit wie möglich zum Internet hin abzuschotten (Motto: "Nur soviel wie nötig, so wenig wie möglich")
Kein Problem. Eine Firewall arbeitet grundsätzlich nach einer Whitelist, d.h. es wird alles geblockt was du nicht explizit freischaltest.
Nethserver muss in der Lage sein Updates zu ziehen, wobei ich bisher nicht herausfinden konnte welche Ports dafür genutzt werden, ich vermute 80 (HTTP) und/oder 443 (HTTPS)
Die Distribution Nethserver nutzt YUM als Paketmanager, also ja, es wird eine HTTP Freigabe benötigt.
Nextcloud soll sowohl vom Internet als auch vom LAN aus erreichbar sein
Der SMB Fileserver soll nur aus dem LAN errreichbar sein.
Der SMB Fileserver soll nur aus dem LAN errreichbar sein.
Na dann einfach die Regeln setzen...
Das LAN soll soweit wie "praktikabel" geschützt sein, so dass ich nicht ständig Regeln hinzufügen muss. Ich denke "allow any" bildet das Verhalten eines üblichen Consumer Routers ab und ist erstmal eine praktikable Einstellung?
Nein, dann wäre ja die Firewall wieder überflüssig....Eine allow any Freigabe ist immer schwachsinn und sollte höchstens nur zum testen verwendet werden. Wer Sicherheit möchte, muss auch etwas Bequemlichkeit aufgeben. Zumal du ganz sicher nicht ständig Änderungen an deinem Regelwerk durchführen musst, besonders weil das ganz sicher doch nur ein privates Projekt in deinem Heimnetz ist, oder?
Übrigens haben die meisten Endkunden nur ein Router und benötigen keine DMZ, daher kommt vielleicht deine Einschätzung.
MfG
die Änderungen wären zu umfangreich.
Dann änderst du eben nur ein oder 2 Zeilen auf einmal und das hintereinander ! 
Zum Rest haben die Kollegen oben schon alles gesagt.
Wichtig für dich: Beim Regelwerk gilt immer:
- ZUERST schriftlich ein Policy bzw. Regelwerk festlegen und Regeln genau danach umsetzen. Niemals blind und ohne Plan etwas erstellen.
- Regeln möglichst nur INbound erstellen
- Es gilt: "First match wins !" sprich der erste positive Hit im Regelwerk bewirkt das der Rest NICHT mehr abgearbeitet wird. Deshalb = Die Reihenfolge zählt !
Übrigens haben die meisten Endkunden nur ein Router und benötigen keine DMZ
Solche Äußerungen sind in einem Admin Forum nicht nur gefährlich sondern auch laienhaft falsch und zeigen eher einen recht eingeschränkten Wissenhorizont auf mit wenig Erfahrung im Netzwerk Umfeld. Sowas mag stimmen für die kleine Klempnerbude von Meister Röhricht mit Ekkehardt und Werner aber ganz sicher nicht für ein Unternehmen einer bestimmten Größe und Security Policy wie sie in seriösen Firmen ja generell üblich ist.
Solche Äußerungen sind in einem Admin Forum nicht nur gefährlich sondern auch laienhaft falsch und zeigen eher einen recht eingeschränkten Wissenhorizont auf mit wenig Erfahrung im Netzwerk Umfeld. face-sad
Sowas mag stimmen für die kleine Klempnerbude von Meister Röhricht mit Ekkehardt und Werner aber ganz sicher nicht für ein Unternehmen einer bestimmten Größe und Security Policy wie sie in seriösen Firmen ja generell üblich ist.
face-sadSowas mag stimmen für die kleine Klempnerbude von Meister Röhricht mit Ekkehardt und Werner aber ganz sicher nicht für ein Unternehmen einer bestimmten Größe und Security Policy wie sie in seriösen Firmen ja generell üblich ist.
Von dem Begriff "Consumer Routers" gehe ich von einem Privathaushalt aus. Ich kenne niemanden der mehr als nur eine Fritzbox und übliche L2 Switche besitzt. Wozu auch?
Bei Firmenumgebungen, egal ob klein oder groß, sieht das selbstverständlich anders aus! Da ist eine Firewall, eine DMZ und eine getrennte VLAN Umgebung quasi Pflicht.
Das sind aber auch komplett andere Anforderungen....
Zitat von @148848:
Moin,
Kein Problem. Eine Firewall arbeitet grundsätzlich nach einer Whitelist, d.h. es wird alles geblockt was du nicht explizit freischaltest.
OK, dann belasse ich die Regeln für die DMZ erstmal so.Moin,
Mein Ziel ist es die DMZ soweit wie möglich zum Internet hin abzuschotten (Motto: "Nur soviel wie nötig, so wenig wie möglich")
Kein Problem. Eine Firewall arbeitet grundsätzlich nach einer Whitelist, d.h. es wird alles geblockt was du nicht explizit freischaltest.
Wobei ich mir nicht sicher bin ob die 2. & 6. (letzte) Regel sinnvoll sind.
Die 2. soll verhindern das ein anderer DNS genutzt werden kann als in der 1. Regel erlaubt (hier die FW als DNS)
Und die 6. Regel verhindert alle Verbindungen außer die die in den darüber aufgeführten Regeln erlaubt sind. Im Sinne deiner Aussage wäre die 6. Regel überflüssig, oder?
Nethserver muss in der Lage sein Updates zu ziehen, wobei ich bisher nicht herausfinden konnte welche Ports dafür genutzt werden, ich vermute 80 (HTTP) und/oder 443 (HTTPS)
Die Distribution Nethserver nutzt YUM als Paketmanager, also ja, es wird eine HTTP Freigabe benötigt.
Nextcloud soll sowohl vom Internet als auch vom LAN aus erreichbar sein
1. Ich richte ein Port Forwarding ein und leite HTTP & HTTPS von WAN an Nethserver weiter.
oder
2. Ich richte für WAN ein Regel ein die HTTP & HTTPS in die DMZ erlaubt.
Der SMB Fileserver soll nur aus dem LAN errreichbar sein.
Na dann einfach die Regeln setzen...
Das LAN soll soweit wie "praktikabel" geschützt sein, so dass ich nicht ständig Regeln hinzufügen muss. Ich denke "allow any" bildet das Verhalten eines üblichen Consumer Routers ab und ist erstmal eine praktikable Einstellung?
Nein, dann wäre ja die Firewall wieder überflüssig....Eine allow any Freigabe ist immer schwachsinn und sollte höchstens nur zum testen verwendet werden. Wer Sicherheit möchte, muss auch etwas Bequemlichkeit aufgeben. Zumal du ganz sicher nicht ständig Änderungen an deinem Regelwerk durchführen musst, besonders weil das ganz sicher doch nur ein privates Projekt in deinem Heimnetz ist, oder?
Übrigens haben die meisten Endkunden nur ein Router und benötigen keine DMZ, daher kommt vielleicht deine Einschätzung.
Dann lege ich auch für das LAN Regeln an, habe allerdings noch keinen Überblick wie dies für den Hausgebrauch aussehen könnte, als Orientierung habe ich folgendes Kapitel der Doku von pfsense zu Rate gezogen
https://docs.netgate.com/pfsense/en/latest/recipes/example-basic-configu ...
Wäre das ein sinnvolles Grundsetup, oder gibt es etwas was geändert/hinzugefügt werden sollte?
Ich vermute es gibt kein "Standard Regelwerk" für das LAN mit dem ich erstmal loslegen und dann Schritt für Schritt verfeinern kann, ich werde wohl gleich mal losziehen müssen und schauen was bei uns so alles genutzt wird und mir die entsprechenden Ports raus suchen.
MfG
Und die 6. Regel verhindert alle Verbindungen außer die die in den darüber aufgeführten Regeln erlaubt sind.
Ist aber völlig überflüssiger Overhead, denn auf einer Firewall gilt bekanntlich IMMER ein grundsätzliches deny any any. Sprich also alles was nicht explizit erlaubt ist das ist auch verboten ! (Whitelist Prinzip)Insofern ist diese Regel überflüssiger Unsinn und kann auch völlig entfallen da sie keinerlei Funktion hat.
Mit dem Wissen ist dann auch Regel 2 unsinnig. WO sollen denn im DMZ Segment auch andere IP Adressen als Source herkommen die nicht DMZ Net sind ? Ist ja utopisch und auch wenn dem so wäre sind sie durch die obige Grundregel so oder so verboten bzw. geblockt.
Sprich also: 2 und 6 ist völlig funktionslos.
Wie sähe die am geschicktesten aus, nach meinem Kenntnisstand werden dafür die Ports
Aktuelle SMB Versionen nutzen nur noch TCP 445. Alles andere sind nicht mehr verwendete Relikte aus der NetBIOS Zeit.Deine aktuelle Konfig ist dafür also OK, denn der SMB Server kann zumindestens per SMB aktiv nirgendwo hin, denn du lässt aus der DMZ gewollt ja nur DNS, HTTP, HTTPs und NTP zu aber kein SMB. Wenn du es wie ein Admin richtig "DMZ like" machen würdest, würdest du das auch nur für diese expliziten Server IPs dediziert zulassen und nicht als Schrotschuss für das ganze DMZ Segment.
Dennoch ist der SMB Server aus dem internen LAN aber erreichbar weil die Firewall stateful arbeitet. Von anderen Segmenten hat ein SMB Zugriff mit TCP 445 ein gesetztes ACK Bit im TCP Header was die Firewall, salopp gesagt, als gewollten Rücktraffic ansieht (stateful) und passieren lässt.
Aktiver SMB Zugriff über das WAN ist per Firewall Regel am WAN Port generell unmöglich.
Fazit: Alles so lassen für SMB.
Um das zu überwachen genügt auch immer ein Blick in das Firewall Log der OPNsense ! 😉
Zitat von @aqui:
Das habe ich auch so gemacht, für einige Änderungen funktionierte dies aber nicht mehr, irgendwann wollte ich nur noch einen Satz hinzufügen, wurde aber mit og. Hinweis verweigert?!?die Änderungen wären zu umfangreich.
Dann änderst du eben nur ein oder 2 Zeilen auf einmal und das hintereinander ! Zum Rest haben die Kollegen oben schon alles gesagt.
Wichtig für dich: Beim Regelwerk gilt immer:
Ja genau so ist mein Vorgehen, aber mir fehlt schlicht und ergreifend noch der Überblick, deshalb bin ich auf der Suche nach Beispielen, Gedankenanstöße und Hinweisen wohin ich meine Blicke wenden muss damit ich erlerne was bei der Erstellung des Plans zu beachten ist.Wichtig für dich: Beim Regelwerk gilt immer:
- ZUERST schriftlich ein Policy bzw. Regelwerk festlegen und Regeln genau danach umsetzen. Niemals blind und ohne Plan etwas erstellen.
Weiterhin erarbeite ich mir gerade den Umgang mit OPNsense und das Erstellen der Firewall Regeln, einiges dazu muss ich ausprobieren damit ich sehe wie das funktioniert, deshalb auch erstmal alles in einem virtuellen Netzwerk.
* Regeln möglichst nur INbound erstellen
Sowas mag stimmen für die kleine Klempnerbude von Meister Röhricht mit Ekkehardt und Werner aber ganz sicher nicht für ein Unternehmen einer bestimmten Größe und Security Policy wie sie in seriösen Firmen ja generell üblich ist.
- Es gilt: "First match wins !" sprich der erste positive Hit im Regelwerk bewirkt das der Rest NICHT mehr abgearbeitet wird. Deshalb = Die Reihenfolge zählt !
Übrigens haben die meisten Endkunden nur ein Router und benötigen keine DMZ
Solche Äußerungen sind in einem Admin Forum nicht nur gefährlich sondern auch laienhaft falsch und zeigen eher einen recht eingeschränkten Wissenhorizont auf mit wenig Erfahrung im Netzwerk Umfeld. Sowas mag stimmen für die kleine Klempnerbude von Meister Röhricht mit Ekkehardt und Werner aber ganz sicher nicht für ein Unternehmen einer bestimmten Größe und Security Policy wie sie in seriösen Firmen ja generell üblich ist.
Wärnää, tut dat not...
wurde aber mit og. Hinweis verweigert?!?
Dann musst du noch kleiner werden und das wortweise oder 2er wortweise machen. Man kann diese Warnung schon etwas intelligent überwinden wenn man denn Geduld hat ! Zitat von @aqui:
Insofern ist diese Regel überflüssiger Unsinn und kann auch völlig entfallen da sie keinerlei Funktion hat.
Mit dem Wissen ist dann auch Regel 2 unsinnig. WO sollen denn im DMZ Segment auch andere IP Adressen als Source herkommen die nicht DMZ Net sind ? Ist ja utopisch und auch wenn dem so wäre sind sie durch die obige Grundregel so oder so verboten bzw. geblockt.
Sprich also: 2 und 6 ist völlig funktionslos.
Verstanden, ich ahnte schon so etwas, war mir aber nicht sicher, also die Regel 2 & 6 fliegen raus.Und die 6. Regel verhindert alle Verbindungen außer die die in den darüber aufgeführten Regeln erlaubt sind.
Ist aber völlig überflüssiger Overhead, denn auf einer Firewall gilt belanntlich IMMER ein grundsätzliches deny any any. Sprich also alles was nicht explizit erlaubt ist das ist auch verboten ! (Whitelist Prinzip)Insofern ist diese Regel überflüssiger Unsinn und kann auch völlig entfallen da sie keinerlei Funktion hat.
Mit dem Wissen ist dann auch Regel 2 unsinnig. WO sollen denn im DMZ Segment auch andere IP Adressen als Source herkommen die nicht DMZ Net sind ? Ist ja utopisch und auch wenn dem so wäre sind sie durch die obige Grundregel so oder so verboten bzw. geblockt.
Sprich also: 2 und 6 ist völlig funktionslos.
Wie sähe die am geschicktesten aus, nach meinem Kenntnisstand werden dafür die Ports
Aktuelle SMB Versionen nutzen nur noch TCP 445. Alles andere sind nicht mehr verwendete Relikte aus der NetBIOS Zeit.Deine aktuelle Konfig ist dafür also OK, denn der SMB Server kann zumindestens per SMB aktiv nirgendwo hin, denn du lässt aus der DMZ gewollt ja nur DNS, HTTP, HTTPs und NTP zu aber kein SMB. Wenn du es wie ein Admin richtig "DMZ like" machen würdest, würdest du das auch nur für diese expliziten Server IPs dediziert zulassen und nicht als Schrotschuss für das ganze DMZ Segment.
Hatte das in meinem Fall als unerheblich eingestuft, da in der DMZ nur dieser eine Server steht. Aber wer weiß was mir in Zukunft noch so alles einfällt..., außerdem möchte ich ja lernen wie man das richtig macht.
Dennoch ist der SMB Server aus dem internen LAN aber erreichbar weil die Firewall stateful arbeitet. Von anderen Segmenten hat ein SMB Zugriff mit TCP 445 ein gesetztes ACK Bit im TCP Header was die Firewall als Rücktraffic ansieht und passieren lässt.
Mit meinen eigenen Worten zusammengefasst beschreibt das den Umstand, dass eine Firewall die eingehende Antwort auf eine vorher ausgegangene Anfrage grundsätzlich zulässt, richtig?Aktiver SMB Zugriff über das WAN ist per Firewall Regel am WAN Port generell unmöglich.
Fazit: Alles so lassen für SMB.
SMB wollte ich auch nicht vom Internet aus zugänglich machen, nur Nextcloud. Nextcloud wäre über HTTP (Port 80) bzw. HTTPS (Port 443) zu erreichen, mach ich das am besten via Port Forwarding von WAN -> Nethserver oder über eine Firewall Regel WAN -> DMZ/Nethserver?Fazit: Alles so lassen für SMB.
Zitat von @aqui:
wurde aber mit og. Hinweis verweigert?!?
Dann musst du noch kleiner werden und das wortweise oder 2er wortweise machen. Man kann diese Warnung schon etwas intelligent überwinden wenn man denn Geduld hat ! Ok, ich versuche es...
könnte das auch über ein Alias machen, aber ist prinzipiell richtig so?
Jepp, das ist richtig so !Aber wer weiß was mir in Zukunft noch so alles einfällt...
Genau deswegen ! 😉dass eine Firewall die eingehende Antwort auf eine vorher ausgegangene Anfrage grundsätzlich zulässt, richtig?
Ja, das ist richtig sofern sie stateful arbeitet ! Firewalls machen das in der Regel alle. ACLs z.B. auf einem L3 Switch arbeiten im Vergleich dazu nicht stateful.mach ich das am besten via Port Forwarding von WAN -> Nethserver
Jepp, ganz genau wenn du nur eine einzige WAN Port IP auf der Firewall hast !
Vielen Dank für Eure Hilfe, allmählich erschließt sich mir die Thematik 
Auch das Port Forwarding hat geklappt. Meine Nextcloud erreiche ich über meinedomain.de/nextcloud. Wenn jetzt jemand nur meinedomain.de aufruft, dann bekommt er die "Begrüßungsseite" von meinem Nethserver zu sehen, dies würde ich gerne verhindern. Ich möchte, dass nur meinedomain.de/nextcloud zu erreichen ist und alle anderen Aufrufe geblockt werden. Gibt es einen Weg wie man das umsetzen könnte?
Auch das Port Forwarding hat geklappt. Meine Nextcloud erreiche ich über meinedomain.de/nextcloud. Wenn jetzt jemand nur meinedomain.de aufruft, dann bekommt er die "Begrüßungsseite" von meinem Nethserver zu sehen, dies würde ich gerne verhindern. Ich möchte, dass nur meinedomain.de/nextcloud zu erreichen ist und alle anderen Aufrufe geblockt werden. Gibt es einen Weg wie man das umsetzen könnte?
dies würde ich gerne verhindern.
Das machst du auf dem Nethserver in der Document Root des Webservers mit einem HTTP Redirect indem du in die index.html dort einen einfachen Einzeiler schreibst: <meta http-equiv="refresh" content="0; url=/nextcloud" /> https://fedingo.com/how-to-redirect-subfolder-to-root-in-apache/
https://serverfault.com/questions/9992/how-to-get-apache2-to-redirect-to ...
usw.
Danke für die Hinweise, schau ich mir als nächstes an.
Versuche mich gerade schlau zu machen in dem Thema OPNsense und Let's Encrypt. Bisher hat sich Nethserver das Zertifikat selbst geholt, aber seit dem Umstieg auf OPNsense bekomme ich Zertifikatswarnung. Wäre ein Thema für einen neuen Thread, aber erstmal muss ich mich da einarbeiten.
Versuche mich gerade schlau zu machen in dem Thema OPNsense und Let's Encrypt. Bisher hat sich Nethserver das Zertifikat selbst geholt, aber seit dem Umstieg auf OPNsense bekomme ich Zertifikatswarnung. Wäre ein Thema für einen neuen Thread, aber erstmal muss ich mich da einarbeiten.
https://github.com/opnsense/plugins/pull/66
Wenn's das denn erstmal war nicht vergessen den Thread zu schliessen:
Wie kann ich einen Beitrag als gelöst markieren?
Wenn's das denn erstmal war nicht vergessen den Thread zu schliessen:
Wie kann ich einen Beitrag als gelöst markieren?
Es hapert bei mir schon an der Challenge, hab einen neuen Thread dazu eröffnet.
Lets Encrypt Zertifikate unter OPNsense
Lets Encrypt Zertifikate unter OPNsense
