Firewallregel - Grundsatzfrage - Funktionsweise?

[opnsense_user12123]

Es ist mir noch immer nicht ganz klar wie die Firewallregel unter OPNsense funktioniert.
Es sind ein paar Fragen die ich mir noch immer nicht ganz erklären kann.

Gehen wir von zwei Pcs aus. Und ich hätte zwei LAN Interfaces. Jeder der PCs wäre in einem unterschiedlichem Subnetz. Nennen wir sie LAN1(PC1) und LAN2(PC2).

PC1 (LAN1) hat die IP 192.168.10.1 und PC2 (LAN2) hat die IP 192.168.20.1

Am PC2 läuft ein Webserver auf 192.168.20.1 Port 8888

Nun möchte ich das der PC1 Zugriff auf den Weberver PC2 bekommt.

1. Dazu würde ich eine Firewallregel im LAN1.net oder spezifisch als Source den PC1 und als Destination den PC2 mit dem Port 8888 definieren.

Frage zu 1.
welcher Port in welchem Netz ist nun offen? Im LAN1 oder am LAN2 Netz oder in beiden und auch in beide Richtungen?
Funktioniert dadurch auch der Datenverkehr vom PC2 auf den PC1 zurück aber ohne dass ich eine Anfrage vom PC1 an den PC2 schicke?

2. Man kann bei einer Firewall Regel unter anderem das Interface, Source und Destination bestimmen.

Frage zu 2.
Wenn ich jetzt als Interface LAN1 auswähle, aber als Source LAN2 und als Destination WAN.
Welche Auswirkungen hätte die Regel dann? Diese Regel ergebe für mich gar keinen Sinn ist aber definierbar.

Vielleicht ist irgendjemand so nett und kann einfach mal im Detail eine Firewallregel und deren Aufbau und Funktionsweise im Detail beschreiben. Sozusagen „Idiotensicher“. Denn nach zahlreichen gelesenen Forum-Postings zu dieser Frage bin ich jetzt eher verwirrter als klüger.

DANKE

[theq86]

Hallo. Wie ich auch gestern erst erfahren habe filtert die Firewall nur eingehende Pakete. Das bedeutet allgemein gesprochen: Pakete die aus Richtung der Firewall nach außen  gehen (außen ist in dem Fall aus der Firewall heraus. Egal ob es ins LAN Netzwerk, WAN Netzwerk oder sonstwo hin geht) werden nicht behandelt.

1.
In deinem Beispiel könntest du an LAN1 keine Antworten des Webservers an den Client behandeln, da aus LAN1-Sicht diese Antwort AUSGEHEND (nach LAN1) ist.

Und daher ist es auch richtig, dass du die Erlaubnis für PC1 auf PC2 zuzugreifen auf LAN1 gibst, denn auf LAN2 wäre das ja wieder ausgehend (raus aus der Firewall zum Server-PC).

Unsicher bin ich mir jetzt, ob du eine LAN2 Regel brauchst, die Traffic vom Server ins LAN1 oder an PC1 erlaubt. Denn stateful firewall bedeutet, dass sobald eine Verbindung steht, auch die Antwort durchgelassen wird.

In dem Fall musst du überlegen: Soll der Server-PC von sich aus auch ins LAN1 dürfen, oder nur, wenn von von LAN1 Seite aus eine Verbindung angefordert wird.

2.
Diese Regel hätte in der Tat keinen Sinn, da sie niemals getriggert werden kann. Denn ein Paket das an LAN2 in die Firewall reinkommt und an WAN aus der Firewall raus geht wird nicht die LAN1 Schnittstelle durchlaufen.
Dennoch ist es konfigurierbar, das stimmt.

[chemlud]

Frage 1:

Du gibst Port 8888 als TARGET port an (Source port ist random, ausgehend die ports alle offen, wenn der Tagret port erlaubt ist). Also ist im NET2 port 8888 "offen" (erreichbar) aus Netz 1

Wenn die Anfragepakete an den Server im Net 2 aus dem Interface Net11 rausgehen wird ein State erzeugt, der automatisch die Antwortpakete aus Net2 in Net 1 zurücklässt (stateful firewall).

Frage 2:

Was wolltest du mit dieser Regel erreichen? Primäre machen Regeln mit "Source" im jeweiligen Netz des entsprechenden Interface Sinn. Wenn du Zweifel hast, bau dir mal dein Szenario auf (mit Hardware oder virtuell) und spiel damit rum. Nur mit "Allow" Regeln auf dem WAN Interface sehr vorsichtig sein, damit exponierst du deine lokalen Rechner direkt dem Internet. Das kann sehr schnell sehr schief gehen...

[opnsense_user12123]

Hallo. Wie ich auch gestern erst erfahren habe filtert die Firewall nur eingehende Pakete. Das bedeutet allgemein gesprochen: Pakete die aus Richtung der Firewall nach außen  gehen (außen ist in dem Fall aus der Firewall heraus. Egal ob es ins LAN Netzwerk, WAN Netzwerk oder sonstwo hin geht) werden nicht behandelt.

1.
In deinem Beispiel könntest du an LAN1 keine Antworten des Webservers an den Client behandeln, da aus LAN1-Sicht diese Antwort AUSGEHEND (nach LAN1) ist.

Und daher ist es auch richtig, dass du die Erlaubnis für PC1 auf PC2 zuzugreifen auf LAN1 gibst, denn auf LAN2 wäre das ja wieder ausgehend (raus aus der Firewall zum Server-PC).

Unsicher bin ich mir jetzt, ob du eine LAN2 Regel brauchst, die Traffic vom Server ins LAN1 oder an PC1 erlaubt. Denn stateful firewall bedeutet, dass sobald eine Verbindung steht, auch die Antwort durchgelassen wird.

In dem Fall musst du überlegen: Soll der Server-PC von sich aus auch ins LAN1 dürfen, oder nur, wenn von von LAN1 Seite aus eine Verbindung angefordert wird.

2.
Diese Regel hätte in der Tat keinen Sinn, da sie niemals getriggert werden kann. Denn ein Paket das an LAN2 in die Firewall reinkommt und an WAN aus der Firewall raus geht wird nicht die LAN1 Schnittstelle durchlaufen.
Dennoch ist es konfigurierbar, das stimmt.

Super. Ich danke dir für die Erklärung. Jetzt muss ich mir das Ganze mal durch den Kopf gehn lassen und das Ganze mal verarbeiten. Sollten sich weitere Fragen ergeben wäre ich dir sehr dankbar wenn du mir mit deinem Wissen helfen könntest. :-)

Frage 1:

Du gibst Port 8888 als TARGET port an (Source port ist random, ausgehend die ports alle offen, wenn der Tagret port erlaubt ist). Also ist im NET2 port 8888 "offen" (erreichbar) aus Netz 1

Wenn die Anfragepakete an den Server im Net 2 aus dem Interface Net11 rausgehen wird ein State erzeugt, der automatisch die Antwortpakete aus Net2 in Net 1 zurücklässt (stateful firewall).

Frage 2:

Was wolltest du mit dieser Regel erreichen? Primäre machen Regeln mit "Source" im jeweiligen Netz des entsprechenden Interface Sinn. Wenn du Zweifel hast, bau dir mal dein Szenario auf (mit Hardware oder virtuell) und spiel damit rum. Nur mit "Allow" Regeln auf dem WAN Interface sehr vorsichtig sein, damit exponierst du deine lokalen Rechner direkt dem Internet. Das kann sehr schnell sehr schief gehen...

Auch dir danke für deine Hilfe. Zur 2. Frage kann ich nur sagen, dass meine Frage ausschließlich dem Verständniszweck diente und du mir mit deiner Antwort meine Frage perfekt beantwortet hast. Denn ich frage mich halt, warum man dann eigentlich diese Auswahl hat. Man könnte die Netze die nicht möglich sind ja gleich ausblenden. Führt meiner Ansicht nach nur zu einer Verunsicherung bzw zu einem Missverständnis.

Aber wie gesagt... Beide Infos muss jetzt mal "sacken" lassen und schauen in wiefern sich jetzt weitere Fragen ergeben. Das Szenario, dass ich oben beschrieben habe war rein fiktiv. Diente also nur der Verständnisfrage!

DANKE mal für die Unterstützung! :-)

[opnsense_user12123]

und da wäre schon wieder die nächste Frage.

Also behandle ich die Filterregeln von innen nach außen?

Das heißt eine Filterregel auf z.b Interface "LAN1" bestimmt den Traffic von innen(Source) nach außen (Destination)?
Und die Antwort kann da ja eine Stateful Packet Inspection Firewall automatisch zurückkommen. Wird dafür automatisch der gleiche Port verwendet oder ein random Port generiert?

Wenn ich aber eine Anfrage von Interface "LAN2" nach "LAN1" machen will, muss ich die Regel am Interface LAN2 erstellen.

Reales Beispiel. FRAGE!

Möchte ich mit meinem Drucker vom "LAN1" Interface zum Drucker "LAN2" Interface per RAW (Port 9100) einen Druckjob schicken wollen, würde es reichen eine Regel am "LAN1" interface zu erstellen.
Möchte ich per HTTP auf die GUI des Druckers zugreifen, würde da auch eine Regel vom "LAN1" auf das "LAN2" Interface "Port 80" reichen?

[chemlud]

Die Pakete (und diese sind es ja, die vom pf = package filter evaluiert werden) werden am ERSTEN Interface evaluiert, auf welches sie treffen.

Pakete aus dem WAN -> am WAN Interface.

Pakete aus dem LAN1 -> am LAN1 Interface. Jeweils nach den dort hinterlegten Regeln (außer es sind ANTWORTpakete auf Anfragen, dann gelten die States, die bei der Versendung der entsprechenden Anfragepakete erstellt wurden).

Welche ports verwendet werden an der Ausgangsmaschine siehst du in der States table. Ist aber eigentlich nicht relevant, oder?

Zu deinen Fragen: Ja, jeweils die IP des Source-Gerätes (Drucker im LAN1) (port: any, da ja random) im LAN 1 wird in den Firewallregeln für LAN 1 erlaubt zur Destination (IP des Geräts in LAN2, port: 9100 oder 80, je nach gewünschtem Service).

Aber seit wann schickt man Druckaufträge von einem Drucker zum anderen? Ich erlaube z.B. das LAN1 Netz in den Friewallregeln von LAN1 das Drucken auf dem Drucker in LAN2 (specifische IP und port z.b. 9100). Funktioniert so. Das Einrichten eines Druckers (HP und Konsorten), insbesondere die Erkennung auf dem Rechner in LAN1, kann manchmal ein bischen schmerzhaft sein und mehr als nur port9100 erfordern, je nachdem, wie und von welchem Betriebssystem aus der Drucker installiert werden soll. Aber das ist eine andere Geschichte.

[opnsense_user12123]

Aber seit wann schickt man Druckaufträge von einem Drucker zum anderen?

Sorry meinte natürlich vom PC1 im LAN1 auf den Drucker im LAN2!

[opnsense_user12123]

1. Kennt jemand eine wirklich gute Anleitung für OPNsense oder PFsense zum Thema Regeln bzw kennt jemand ein gutes Tutorial? (zum nachlesen für alle Fälle)

Danke an alle die mir geholfen haben die Regeln besser zu verstehen! :-)

[opnsense_user12123]

Hab für einen bestimmten Rechner im meinem Netzwerk eine Regel erstellt um ein Spiel "Unreal Tournament" zu spielen. Dafür werden einige Ports benötigt.
Um diese Regel nur auf diesen einen Rechner zu beschränken gibt es nun zwei Möglichkeiten

Möglichkeit 1:
Allow -> PC1 -> Dest: spezielle Destination Ports

Möglichkeit 2:
Block -> !PC1 -> Dest: spezielle Destination Ports

Die eine Regel erlaubt es nur diesem Rechner. Ist das richtig?
Die zweite Regel erlaubt es niemandem außer diesem bestimmten Rechner! Ist das richtig?

Was wäre den die besser bzw sicherere Regel?

Screenshots anbei!

[theq86]

Logisch betrachtet führen beide Regeln zum selben Ergebnis.

Es gibt aber einen feinen Unterschied:
Die opnSense blockiert standardmäßig alles was nicht explizit auf allow steht.
Ein Block ist aber ein Block und kein Allow. Soll heißen, die Negation macht den Block nicht zu einem expliziten Allow.

Würde die FW alles erlauben, es sei denn es ist blockiert, dann würden Nummer 1 und 2 funktionieren.

[opnsense_user12123]

Logisch betrachtet führen beide Regeln zum selben Ergebnis.

Es gibt aber einen feinen Unterschied:
Die opnSense blockiert standardmäßig alles was nicht explizit auf allow steht.
Ein Block ist aber ein Block und kein Allow. Soll heißen, die Negation macht den Block nicht zu einem expliziten Allow.

Würde die FW alles erlauben, es sei denn es ist blockiert, dann würden Nummer 1 und 2 funktionieren.

Ok. Danke für den Hinweise. Also ist der spezifische Allow der richtige Weg. Habe ich dich richtig verstanden?

Aber was wären jetzt die genauen Auswirkungen bzw Nebenwirkungen bei Möglichkeit 2 (Block?)

[JeGr]

1. Kennt jemand eine wirklich gute Anleitung für OPNsense oder PFsense zum Thema Regeln bzw kennt jemand ein gutes Tutorial? (zum nachlesen für alle Fälle)

Danke an alle die mir geholfen haben die Regeln besser zu verstehen! :-)

Ahoi,

zuerst einmal wäre es vielleicht schön, weniger in Fett zu schreiben, das macht das Lesen ein wenig einfacher - ist aber nur mein subjektives Empfinden. Bei mir sieht das eher wie CAPS aus und das ist so _schreiend_

Ansonsten ist das Regelkonzept von PF - und das ist der Filter hinter pfSense wie opnSense - recht einfach:

Betrachte deine Firewall als Blackbox. Schwarzer Kasten, wo Drähte reingehen. Funktion o.ä. völlig egal.
Wenn du dir jetzt überlegst, wie eine spezifische Regel lauten muss, dann musst du nur diese Dinge verstehen/überlegen:

1) Der schwarze Kasten verbietet alles per default. Ist etwas nicht explizit erlaubt, wird sich nichts bewegen.
2) Hangel dich an deinem Draht entlang: WO trifft deine Anfrage ZUERST auf die Sense. DAS ist das Interface, auf welchem du die Regel anlegst. Antwort-Verkehr, der daraus resultiert (bspw. HTTP Traffic: alle Antworten des Webserver) wird durch den angelegten State automagisch erlaubt. Ausnahme sind seltsame Protokolle wie FTP.
3) Source, Destination: Source ist WO dein Paket herkommt bzw. erzeugt wird (meist der Rechner von dir selbst oder von außen, der irgendetwas abrufen möchte). Destination dein Ziel, das den Dienst anbietet. Egal ob dein Ziel in einem anderen Netz, Schloß oder sonstwas ist -> 2) ist hier entscheidend, WO (Interface) du die Regel anlegst. Was darin steht ist die Sache, was du machen möchtest.


Um dein Beispiel aufzugreifen: UT im Internet auf Server X spielen mit PC1. PC1 steht im LAN1. Um das zu erlauben:

LAN1 Interface Tab:
Allow (Pass in) Proto (TCP/UDP) from SRC (PC1) Port (any) TO DST (ServerX) Port (UT Ports) Gateway * (default).

Warum? Siehe oben! LAN1 Interface, weil der PC dort hängt und noch wichtier: der PC baut die Verbindung auf! Nicht der Server zum PC! Daher: Paket trifft zuerst auf LAN1.
Allow - denn es muss generell erstmal etwas erlaubt werden, sonst ist alles verboten.
Protokoll ist TCP oder UDP, das hängt vom Spiel an, manchmal auch beides.
Source ist logischerweise PC1
Source Port ist allermeistens any (weil meist random >1023)
Destination ist der ServerX
Destination Ports sind die Game Ports des Servers
Gateway bleibt Default

Fertig

Das einzige was noch wichtig bei dieser Betrachtung ist, ist der Sonderfall WAN/Port Weiterleitung. Da die Port Forwards (NAT/RDR) Einträge VOR den Filterregeln bearbeitet werden, wird das Paket vor dem Auftreffen auf das WAN IF bereits umgestempelt: Leitet man bspw. wie Forwarding Port 8080 intern auf Port 8080 weiter, so ist die Destination IP des Pakets die interne(!) IP auf die weitergeleitet wird, nicht die IP auf dem WAN. Nur wenn das Paket nicht vorher umgestempelt wird, taucht es mit der externen Adresse auf dem WAN auf, dann weiß man, dass man bei den Port Forwarding Regeln / NAT Regeln wohl was falsch gemacht hat.

Grüße