OPNsense Forum
International Forums => German - Deutsch => Topic started by: vinz on September 09, 2016, 09:58:50 am
-
Hallo, ich bin neu hier und verstehe das Firewall Regelwerk noch nicht ganz.
Source/Destination:
- This Firewall
Was bedeutet das? 127.0.0.1/8 oder alle [IFACE] Adressen? - [IFACE] address
Das ist das statisch definierte oder per DHCP zugewiesene Adresse dieses Interfaces. Könnten es auch mehrere sein? Sinnvoll bei allen Regeln nur für lokale Services auf der Firewall? - [IFACE] net
Siehe address, aber das ganze Subnet.
Macht das Subnet als Regel-Source überhaupt Sinn? Es ist ja durch das Subnet eh gegeben?
Ausser bei Zugriffen per externem port-forwarding auf das [WAN] Interface (Unterscheidet Quelle WAN-net oder Internet).
Firewall: Rules: Reihenfolge:
- Werden die Floating Regeln oder die Interfaces zuerst bearbeitet? Ich vermute Floating.
- Wenn eine Floating-Regel mit Aktion zutrifft (allow, reject, block), werden dann die Interfaces-Regeln gar nicht mehr durchlaufen!?
Das wiederspricht meinem Netfilter-Kopf :-)
Floating Rules
- Grundregel: alles erlaubt, bzw. keine Aktion.
- Regeln werden von oben nach unten abgearbeitet. Bei einem Treffer wird die Aktion erstmal nur verändert.
- Auslösen der Aktion sofort, nur wenn Quick (action immediately) aktiv.
- Wenn Regeln zugetroffen haben (allow, reject, block), so gelten diese endgültig! Dann keine Bearbeitung der Interface-Regeln mehr. Stimmt das??
- Also: Weiter mit den Interface-Regeln nur dann, wenn hier keine Regel zugetroffen hat. Stimmt das??
Interfaces [IFACE] Rules
- Grundregel: Alles blockiert (nicht rejected)?
- Regeln werden für alle Pakete durchlaufen, die in Floating nicht "gematcht" haben -
- UND dann initial von aussen auf dieses [IFACE] auftreffen. Also Zugriff auf die Firewall oder Forwarding durch die Firewall.
- Regeln werden von oben nach unten abgearbeitet.
- Erster Match löst Aktion aus und bricht ab.
- Wieso gibt es den Schalter Quick (action immediately) hier nicht?
Firewall: NAT: Outbound:
Mode "Automatic outbound NAT rule genertion".
Ich sehe nur Regeln für mein LAN-Subnetz, wo sind WLAN und DMZ? Wieso funktioniert der Outbound von WLAN und DMZ?
-
Reihenfolge: https://github.com/opnsense/core/blob/master/src/etc/inc/filter.inc#L2884 (https://github.com/opnsense/core/blob/master/src/etc/inc/filter.inc#L2884)
This Firewall
Was bedeutet das? 127.0.0.1/8 oder alle [IFACE] Adressen?
This Firewall: wird in der Konfiguration zu "self", welches alle zugewiesenen IP-Adressen enthält:
https://www.freebsd.org/cgi/man.cgi?pf.conf (https://www.freebsd.org/cgi/man.cgi?pf.conf)
https://www.openbsd.org/faq/pf/tables.html (https://www.openbsd.org/faq/pf/tables.html)
[IFACE] net
Siehe address, aber das ganze Subnet.
Macht das Subnet als Regel-Source überhaupt Sinn? Es ist ja durch das Subnet eh gegeben?
Ausser bei Zugriffen per externem port-forwarding auf das [WAN] Interface (Unterscheidet Quelle WAN-net oder Internet).
Ja, wenn da zum Beispiel ein Router ohne NAT betrieben wird.
Kurze Erklärung zum Schlüsselwort quick:
PF funktioniert nach dem "last Match"-Prinzip. Mit dem Schlüsselwort "quick" wird wie bei einer "first Match"-Firewall die weitere Verarbeitung abgebrochen. Regeln für die Schnittstellen sind immer "quick".
Damit können die Floating Rules vor und nach den Regeln für Schnittstellen zutreffen.
-
vielen Dank für die Links!
github-Code, Reihenfolge:
The order must be: Floating rules, then interface group and then regular ones.
Mit "regular ones" sind in diesem Zusammenhang die Interface-Rules gemeint?
Das wäre dann die Reihenfolge, die ich beschrieben habe.
Dein Satz verwirrt mich, obwohl ich alles zum "quick" nochmal gelesen habe:
Damit können die Floating Rules vor und nach den Regeln für Schnittstellen zutreffen.
Sorry, das geht mir einfach nicht in den Kopf.
Wenn das Pakete in den Interface-Rules ankommt, und da einen Match hat, dann ist die Sache doch entschieden, dann ist nix mehr mit Floating Rules.
Wenn das Paket in den Interface-Rules keinen Match hat, dann ..
Aha! Ist es so? Die Floating Rules ohne "quick" verändern nur einen Merker (block, reject, accept).
Jetzt kommt das Paket in den Interface-Rules an und wird dort mit dem ersten Match überschrieben und entschieden -- oder, wenn kein Match, dann entspechend dem Floating-Merker verarbeitet.
Die Floating Rule mit "quick" entscheidet sofort und vorrangig zu den Interface-Rules.
Und ergänzend: Der "Merker" steht vom Begin weg auf block.
-
So könnte man es auch erklären ;)
PF arbeitet die Regeln von oben nach unten ab. Dabei werden oben die allgemeinen Regeln definiert (z. B. blockiere jeden Datenverkehr) und unten dann die spezielleren (erlaube HTTP auf Port 80). Danach kann man die Regeln noch einmal spezialisieren (z. B. einen einzelnen Host blockieren). Wenn man aber weiß, dass unten nichts mehr kommen sollte, kann man sich die weitere Verarbeitung sparen ("quick"). Die zuletzt von einer Regel gesetzte Aktion wird dann angewandt. Wenn die Regeln für die Schnittstellen nicht zutreffen, ändern sie den Status auch nicht.
PS: in den allgemeinen Einstellungen kannst du die Sprache der Konfigurationsoberfläche umstellen.
-
wow super, vielen Dank für Deine Erläuterungen. Habe das Regelwerk mit diesem Verständnis komplett neu angelegt - grosser Unterschied: Es klappt sofort wie gewünscht. ;D
Demnach sind die Interface-Regeln einfach ganz normale "Floating-Regeln" mit dem Unterschied:
Interface ist vorbelegt, Direction ist IN, Qick ist gesetzt und sie kommen danach.
OK ;) Jetzt bitte zu Regeln die ich nicht sehe oder die fehlen:
Wieso funktioniert der DHCP-Server, ohne das ich ihn freigegeben habe?
Im Firewall-Log sehe ich jede Menge lokale DNS-Zugriffe die geblockt werden: Quelle & Ziel: 127.0.0.1 53/UDP.
Ist das normal? Ich habe diese jetzt mal mit einer Floating-Regel und einem Lokal-Alias 127.0.0.1/8 erlaubt.
In System->Settings->General hat es da was komisches: "Do not use the DNS Forwarder as a DNS server for the firewall" ist inaktiv.
Im Firewall-Log sehe ich das der NTP-Outbound (123/UDP) geblockt wird, der NTP-Server meldet dann Network is unreachable. Eine entsprechende Regel zu fomulieren fällt mir schwer:
Interface WAN, Direction OUT, Source WAN address:*, Destination any:NTP.
Jetzt scheint es mir, als wüde die Antwort geblockt. (die von Ports wie 2, 25, 26 kommt :o) Sollte die nicht automatisch erlaubt sein (state ESTABLISHED,RELATED ::))?
-
NTP erlaube ich so:
Protokoll:IPv4 UDP
Source:LAN (oder OPTx, je nachdem)
Destination: Alias mit deinen beliebtesten NTP servern
Port:123
Funzt! :-D
-
Hallo chemlud,
ich verstehe das so, dass Du damit Clients im LAN Zugriff auf externe NTP-Server erlaubst.
Ich meine aber den Zugriff der Firewall selbst auf externe NTP-Server. So dass sie selbst als NTPd tut.
Jetzt glaube ich, dass mein Direction OUT das Problem ist, weil es wieder erwarten wirklich nur OUT ist. ESTABLISHED,RELATED gibt es wohl nicht :-[ und meine Regel mit IN/OUT erlaubt leider WAN-Zugriff auf den NTPd.
Oder ich muss das hier nach der jeder Regeländerung machen: Firewall: Diagnostics: States Reset ?
Beispiel: Wenn ich eine einschränkende Regel nachträglich baue (ICMP Ping) dann bekommt diese keine Wirkung, wenn ich vorher schon mal gepingt habe. Nach dem Reset funktioniert sie.
-
deleted
-
Im GUI kannst du afaik nur Regeln für die Richtung "IN" definieren.
State Tracking ist in den erweiterten Einstellungen (standardmäßig "Keep State")
Verbindungen die mit "Keep State" erlaubt wurden, werden durch eine Regeländerung bzw. -Löschung nicht getrennt. Da die Regel dann aber nicht mehr da ist, können keine neuen Verbindungen aufgebaut werden. Über "States Reset" wird diese Information verworfen und daher müssen die Regeln erneut durchlaufen werden.
Von der Funktion her ist "Keep State" sowas, als würde man auf Linux als erste Regel folgende definieren:
ct state {established, related} accept
-
Dieses "Keep State" überdauert mehr als ich dachte, Beispiel:
1) Ich habe eine Regel, die ICMP in die DMZ erlaubt.
2) Jetzt deaktiviere ich die Regel, Ping in die DMS ist also gesperrt
Ein erneutes Ping (ECHO REQUEST) funktioniert aber weiterhin.
3) "Reset States" führt dazu, dass die Regel scharf ist. Ping nicht mehr möglich
4) Jetzt aktiviere ich die Regel wieder, Ping funktioniert jetzt sofort.
Wenn man versucht, die ersten Erfahrungen zu machen, kann einen das ganz schön verwirren. :o
Aber vielen Dank für Deine Hilfe!