Probleme mit DMZ bzw. anderen Subnetze

Started by FirstSoul, June 03, 2018, 01:37:33 PM

Previous topic - Next topic
Schön das es jetzt geht. Verstehe aber immer noch nicht warum die von mir vorgeschlagenen Regeln nicht funzten.


Quote from: JeGr on June 05, 2018, 12:59:42 PM
...
Am Einfachsten ist die Regelverarbeitung, wenn man auf Kniffe wie "!<alias>" verzichtet, denn das kann an anderen Stellen wieder seltsame Nebeneffekte haben.
...

Ich nutze für alle meine Regeln, die Zugriff auf Dienste im Internet erlauben sollen, als Destination !LAN_Netze. Damit möchte ich einfach sicherstellen, dass eine Regel nicht doch den Zugriff in ein anderes LAN Subnetz ermöglicht, weil sie an einer falschen Stelle der Reihenfolge steht. Ab einer gewissen Anzahl von Regeln wird es (zumindestens für mich) leicht unübersichtlich.
Aber beides funktioniert, man spart sich nur die ein oder andere Regel.
Duck, Duck, Duck, Duck, Duck, Duck, Duck, Duck, Goose

Vielleicht war es der State Reset. Wobai ich ja die Firewall auch mal komplett neugestartet habe.

Kann mir jemand das nochmal in einfachen Worten erklären, wie die Firewall arbeitet?
oder denke ich richtig:

Am Beispiel LAN (mein Screenshot):

1. Alles wird gesperrt
2. Mein Management Port wird freigegeben
3. OpenVPN wird freigegen
4. Standard Ports werden freigeben (damit allgemein Netzwerkfunktionen laufen)
5. Alles von LAN Netz in ALLE Subnetze (weil im Alias ja auch das LAN Netz drin ist) wird geblockt
6. Alles wird freigeben

Für mich ergibt das einfach kein sinn. Laut z.B. Sophos würde die Regel 6 alle vorherigen aufheben.
Kann mir jemand das in einfachen worten erklären. Ich finde im Netz dazu irgendwie nicht.

Anhand Deines Screenshots (https://cloud.froechtenicht.de/index.php/s/JTmmkYXpXa98Gk2):

Regel 1: Erlaubt den Zugriff aus allen Netzen auf die Management Oberfläche der OPNsense über die IP des LAN Adapters.
Regel 2:  Erlaubt den Zugriff aus dem OpenVPN Netz in alle Subnetze des LANs / hinter dem LAN Adapter
Regel 3: Erlaubt Zugriff aus dem LAN Netz auf Standard Services (DNS, NTP, DHCP) über die IP des LAN Adapters.
Regel 4: Verbietet den Zugriff aus dem LAN Netz in alle anderen lokalen Subnetze
Regel 5: Erlaub den Zugriff aus dem LAN Netz in alle anderen Netze (auch Extern)

Bei einem eingehenden Paket arbeitet die Firewall die Regel nacheinander ab, bis eine Regel passt/matcht. Sobald eine passt werden die nachfolgenden Regeln nicht mehr verarbeitet. Passt keine Regel, wird das Paket durch die Default-Deny-Rule abgelehnt.
Nehmen wir als Beispiel mal eine DNS Anfrage aus Deinem LAN zur OPNsense. Die Regel 1 und 2 passen hier nicht. Das Paket rutscht bis zur Regel 3 durch und hier passt es. Es wird gemäß der Regel die Aktion "Allow" ausgeführt. Fertig. Die nachfolgenden Regeln werden nicht mehr beachtet.
Wenn Du z.B. als Regel 4 eine identische Regel wie Regel 3 nur mit der Aktion "Deny" hättest, würde DNS weiterhin erlaubt da die "Allow" Regel vor der "Deny" Regel steht.
Duck, Duck, Duck, Duck, Duck, Duck, Duck, Duck, Goose

> Und die Alternative? Alles einzeln Freigeben? Nein, danke. Ich bin keine Bank...

Sorry das ist quatsch. Ob du jetzt 3 Regeln oder 4 oder 5 machst, macht wohl den Kohl nicht fett. Das hat nichts mit Bank, sondern Übersichtlichkeit zu tun und die Oberfläche macht durch Regel kopieren etc. das jetzt wirklich einfach. Ist ja nicht so, als müsste man die Dinger per Hand tippen wie früher...

> Am Beispiel LAN (mein Screenshot):

Das was @JasMan schreibt. Die erste Regel ist die AntiLockout Regel. Die zweite macht für mich keinen Sinn, denn es wird kaum auf dem LAN Interface Traffic ANkommen, der aus dem OpenVPN Netz kommt. Der kommt auf dem OpenVPN Netz an und geht AUS dem LAN Netz raus. Gefiltert wird aber immer EINgehend, nicht AUSgehend (Ausnahme Floating Regeln, aber das wäre einen Komplexitätsschritt höher und es sollte ja möglichst einfach und übersichtlich bleiben). Der Rest ist wiederum so wie ich es auch schon beschrieben hatte. Erlaube die Dienste die auf dem LAN ankommen müssen, blocke die anderen LAN/lokalen Netze, erlaube den Rest damit das Internet geht :)

Ich denke was dein Problem ist, ist nicht so sehr die Abarbeitung der Regeln, sondern vielmehr die Denkweise, dass du ein- sowie ausgehende Pakete alle händisch filtern musst. Das ist NICHT der Fall:

Gefiltert wird im Normalfall NUR EINgehender Traffic. Sprich: alles was auf Interface X ankommt, nicht was nach Verarbeitung irgendwo wieder rausgeht. Das wird automatisch gemacht. Genauso der entsprechende Antworttraffic. Der wiederum ist durch stateful firewalling eh schon erlaubt.

Einfaches Beispiel: Du hast im LAN ein NAS stehen. Das hat eine Weboberfläche. Die soll erreichbar sein via VPN (OpenVPN) sowie im LAN. LAN->LAN hat nichts mit der Firewall zu tun, da kannst du natürlich immer drauf zugreifen. Wenn du aus den anderen lokalen Netzen (bspw. LAN2 oder DMZ) drauf zugreifen willst, dann muss auf dem Interface, auf dem das Paket AN das NAS zuerst ankommt, die Regel für die Allow Regel ran. Du sitzt in LAN2? Also muss auf LAN2 eine Regel drauf mit "erlaube Paket von Rechner/LAN2 Netz/etc. nach NAS_im_LAN auf Port 80/443". Dass das Paket daraufhin aus dem LAN Interface wieder rauskommt musst du nicht extra erlauben. Das wird implizit angelegt. Ebenso ist durch stateful firewalling aller Antwort-Traffic vom NAS an deinen Rechner in LAN2 ebenso erlaubt.
Aber der Zugriff aufs NAS soll auch per VPN gehen. Also Laptop an, VPN gestartet, eingeloggt. Wo schlägt das Paket dann auf? Auf dem "virtuellen" OVPN Interface. Ergo muss deine Regel aufs OVPN Interface und ähnlich der LAN2 Regel aus obigem Beispiel aufgebaut sein, à la "erlaube TCP Traffic von OVPN_Netz nach NAS_IM_LAN Port 80/443".

Das natürlich nur ein Beispiel, aber vielleicht wird dadurch das wie und warum der Regeln ein wenig klarer. Zudem gilt: Alles was NICHT durch Regeln auf den Interfaces definiert ist, wird am Ende nochmal durch eine block any Regel geblockt. Trifft auf dein Paket also keine der Regeln bspw. auf dem OpenVPN Interface zu - wird das Paket geblockt.
Ansonsten hatte JasMan ja schon beschrieben, dass PF (der Filter) die Regeln top down abarbeitet. Die erste, die zutrifft wird sofort angewendet und die weitere Verarbeitung abgebrochen. Daher kommt es auf Reihenfolge und Scope (also Geltungsbereich) an.

Ich hoffe das macht es etwas klarer :)
"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.

Quote from: JeGr on June 06, 2018, 09:59:51 AM
> Und die Alternative? Alles einzeln Freigeben? Nein, danke. Ich bin keine Bank...

Sorry das ist quatsch. Ob du jetzt 3 Regeln oder 4 oder 5 machst, macht wohl den Kohl nicht fett. Das hat nichts mit Bank, sondern Übersichtlichkeit zu tun und die Oberfläche macht durch Regel kopieren etc. das jetzt wirklich einfach. Ist ja nicht so, als müsste man die Dinger per Hand tippen wie früher...
Okay, hast recht. Meine Denkweise war etwas anders. Aber ich lasse es jetzt so, weil ich schon kommen sehe:
Meine Freundin kauft Gerät X, konfiguriert das und... es geht nicht. Somit kommt es aufjedenfall raus und kann arbeiten. DAs ist mein gedanke dahinter ;-) Aber das ist ja in jedem sein ermessen ;-)

Danke an euch beide für die Erklärung. Nun habe ich es verstanden. Etwas komplizierter, aber geht.
Mit meinen Worten:

Paket kommt an, erste Regel passt nicht, weiter, nächste Regel passt und wird angewendet, nächstes Paket.

Damit kann ich doch arbeiten :-)