pete55
Goto Top

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)
dmz

Ich habe bisher folgende Firewall Regeln erstellt:

DMZ:

screenshot_dmz

LAN:

screenshot_lan


VG Pete

Content-ID: 1445157905

Url: https://administrator.de/contentid/1445157905

Printed on: November 13, 2024 at 22:11 o'clock

Kuemmel
Kuemmel Oct 30, 2021 at 07:49:37 (UTC)
Goto Top
Moin,

die Frage ist: Was willst du denn erreichen mit deinen Regeln?

Gruß Kümmel
Pete55
Pete55 Oct 30, 2021 updated at 08:20:31 (UTC)
Goto Top
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:
  • 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
148848
148848 Oct 30, 2021 updated at 09:31:09 (UTC)
Goto Top
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.

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.

Na dann einfach die Regeln setzen... face-wink

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
aqui
aqui Oct 30, 2021 updated at 09:38:10 (UTC)
Goto Top
die Änderungen wären zu umfangreich.
Dann änderst du eben nur ein oder 2 Zeilen auf einmal und das hintereinander ! face-sad
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. 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.
148848
148848 Oct 30, 2021 updated at 09:47:09 (UTC)
Goto Top
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 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.

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....
Pete55
Pete55 Oct 30, 2021 at 10:04:43 (UTC)
Goto Top
Zitat von @148848:

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.

OK, dann belasse ich die Regeln für die DMZ erstmal so.
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.

Prima, dann passt das so.

Nextcloud soll sowohl vom Internet als auch vom LAN aus erreichbar sein
Hier bin ich mir nicht sicher welche Lösung die elegantere wäre. Wenn ich das richtig sehe habe ich 2 Möglichkeiten Nextcloud ins Internet zu bringen.
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.
Wie sähe die am geschicktesten aus, nach meinem Kenntnisstand werden dafür die Ports 445 & 139 genutzt, einfach die öffnen?


Na dann einfach die Regeln setzen... face-wink



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.

Verstanden - ja es handelt sich um unser Heimnetz.
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
aqui
aqui Oct 30, 2021 updated at 10:49:03 (UTC)
Goto Top
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. face-wink
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 ! 😉
Pete55
Pete55 Oct 30, 2021 at 10:42:00 (UTC)
Goto Top
Zitat von @aqui:

die Änderungen wären zu umfangreich.
Dann änderst du eben nur ein oder 2 Zeilen auf einmal und das hintereinander ! face-sad
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?!?

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.
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.
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
  • 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. 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.

Wärnää, tut dat not... face-wink
aqui
aqui Oct 30, 2021 updated at 10:46:19 (UTC)
Goto Top
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 ! face-wink
Pete55
Pete55 Oct 30, 2021 updated at 11:45:20 (UTC)
Goto Top
Zitat von @aqui:

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.
Verstanden, ich ahnte schon so etwas, war mir aber nicht sicher, also die Regel 2 & 6 fliegen raus.

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. face-wink
Verstanden, Danke für den Hinweis, ich werde die Regeln von "DMZ net" auf "Single host or Network" + IP des Nethservers ändern - könnte das auch über ein Alias machen, aber ist prinzipiell richtig so?
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?
Pete55
Pete55 Oct 30, 2021 at 11:07:26 (UTC)
Goto Top
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 ! face-wink

Ok, ich versuche es...
aqui
aqui Oct 30, 2021 updated at 13:22:31 (UTC)
Goto Top
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 !
Pete55
Pete55 Nov 02, 2021 at 07:52:55 (UTC)
Goto Top
Vielen Dank für Eure Hilfe, allmählich erschließt sich mir die Thematik face-smile

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?
aqui
aqui Nov 02, 2021 updated at 12:48:12 (UTC)
Goto Top
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" />  
Nicht ganz so quick and dirty like ist es wenn du einen URL Rewrite machst im Apachen.
https://fedingo.com/how-to-redirect-subfolder-to-root-in-apache/
https://serverfault.com/questions/9992/how-to-get-apache2-to-redirect-to ...
usw.
Pete55
Pete55 Nov 02, 2021 at 16:28:47 (UTC)
Goto Top
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.
aqui
aqui Nov 02, 2021 updated at 18:24:48 (UTC)
Goto Top
https://github.com/opnsense/plugins/pull/66

Wenn's das denn erstmal war nicht vergessen den Thread zu schliessen:
How can I mark a post as solved?
Pete55
Pete55 Nov 03, 2021 updated at 10:06:34 (UTC)
Goto Top
Es hapert bei mir schon an der Challenge, hab einen neuen Thread dazu eröffnet.
Lets Encrypt Zertifikate unter OPNsense