[solved] opnsense, pf und ein paar Anfängerfragen

[stoe]

Liebes Forum

Neuling hier; ich bin seit einiger Zeit am Durchforsten des GUI (und des Forums) und bin überwältigt von den Möglichkeiten von OPNsense, vorab also mal Respekt an die Beteiligten!

Nun stellen sich natürlich die üblichen Fragen und auf einige hab ich noch keine Antworten gefunden, sodass ich mir erlaube, sie hier zu stellen:

• Das FreeBSD Handbuch sagt zu PF, dass die last matching rule greift. Das OPNsense GUI sagt dagegen das Gegenteil, dass die erste passende Regel greift. Finde ich sinnvoll, aber unerwartet. Ist das eine Anpassung von OPNsense (oder von HardenedBSD) und welche anderen Besonderheiten des PF müssen beachtet werden?
• Eine frisch installierte OPNsense hat gemäss GUI keine aktiven Regeln an der WAN Schnittstelle, per default würde alles geblockt, was nicht explizit erlaubt sei. Diese default Drop-Regel sehe ich nirgends im GUI, ebenso wenig wie Pass-Regeln vom WAN zum LAN für Traffic mit Status established oder related. Die müssten aber da sein, schliesslich kann ich mit einem client der OPNsense im Internet surfen. Es gibt also (sinnvolle) default Regeln, die im GUI nicht sichtbar sind. Kann ich das im GUI ändern oder wo kann ich sie stattdessen sehen?
• Wie ist das Zusammenspiel von CLI und GUI? Welche Schnittstelle übersteuert die andere (vermutlich das CLI die GUI) und sind Änderungen in der führenden Schnittstelle in der übersteuerten dann auch sichtbar?
• Wo kann ich bei der Erstellung von PF-Regeln im GUI den «state» des Traffics angeben, also ob die Verbindung established, related, new oder invalid ist (ja, ich komme von iptables/EdgeOS  )?
  
• Welche Berechtigung muss ich im GUI einem non-root user geben, damit er im CLI su nutzen kann? Wie befürchtet einfach alle oder gibt es eine bestimmte Berechtigung dafür, root werden zu dürfen?
• Und schliesslich: Wo hätte ich die Antworten auf all diese Fragen finden können, ohne Euch beanspruchen zu müssen? Die Doku hat mir schon viel geholfen, aber grade zur Firewall sagt sie nicht allzu viel und fremde Doku zu PF ist wohl mit Vorsicht zu geniessen (vgl. erste Frage).

Besten Dank für jeden input und nochmals chapeau an die Entwickler/Betreiber/Supporter von OPNsense!

Gruss
stö

[theq86]

Welche Berechtigung muss ich im GUI einem non-root user geben, damit er im CLI su nutzen kann?

Er benötigt die Gruppenmitgliedschaft "admins" - das sorgt auch für eine Verwendbarkeit von sudo, wenn man es einstellt und für eine Zuweisung des Users zur unix-gruppe wheel

Wie ist das Zusammenspiel von CLI und GUI? Welche Schnittstelle übersteuert die andere (vermutlich das CLI die GUI) und sind Änderungen in der führenden Schnittstelle in der übersteuerten dann auch sichtbar?

Es gibt eine Abstraktionsebene für die Konfiguration. CLI-Kommandos und GUI-Einstellungen ändern Einstellungen innerhalb dieser Ebene und sind als gleichwertig zu betrachten.

Ausnahme ist natürlich, wenn du das unterliegende BSD selbst nutzt um zB. EInstellungen und Regeln zu ändern. Dann änderst du das nämlich auf der OS Ebene und der configd-Layer bekommt das nicht mit. Solche Settings sind flüchtig und nach einem Reboot wieder weg.

Und schliesslich: Wo hätte ich die Antworten auf all diese Fragen finden können, ohne Euch beanspruchen zu müssen? Die Doku hat mir schon viel geholfen, aber grade zur Firewall sagt sie nicht allzu viel und fremde Doku zu PF ist wohl mit Vorsicht zu geniessen (vgl. erste Frage).

Vieles erfährst du wirklich nur durch die Suchfunktion des Forums und durch eigene Threads. Ich würde mir wirklich wünschen, dass das OPNsense Wiki offen wäre.

[stoe]

Danke nasq, das hilft mir weiter.

Er benötigt die Gruppenmitgliedschaft "admins" - das sorgt auch für eine Verwendbarkeit von sudo, wenn man es einstellt und für eine Zuweisung des Users zur unix-gruppe wheel

Das bedeutet dann auch, dass der non-root user dieselben Berechtigungen wie root hat und ein su gar nicht mehr nötig wäre, oder? Egal, damit komme ich weiter.

Schönen Tag und Gruss
stö

[theq86]

Nein.

Ein User in der Gruppe Admins hat vollen Zugriff auf die GUI. Er kann auch im CLI Menü Einstellungen vornehmen.
Er ist aber auf FreeBSD Ebene nicht root gleichgesetzt. Das geht auch gar nicht, denn root ist root (uid 0) und kein anderer Nutzer kann die selben Rechte haben wie root. Du benötigst also immer su oder sudo, um Systemadministrationsaufgaben zu erledigen.

Wie auch immer, die Mitgliedschaft in admins sichert dem User zu, dass der su oder sudo überhaupt benutzen darf um root zu werden.

Ich habe root zB. deaktiviert und nutze einen privilegierten adminuser, der nach bedarf dann auch über sudo root-aufgaben machen kann.

[stoe]

Vielen Dank. Dasselbe schwebt mir eben auch vor, drum hab ich gefragt.

Deine Antworten helfen mir weiter, dafür merci.

Besten Gruss
stö

[JeGr]

>- Das FreeBSD Handbuch sagt zu PF, dass die last matching rule greift. Das OPNsense GUI sagt dagegen das Gegenteil, dass die erste passende Regel greift. Finde ich sinnvoll, aber unerwartet. Ist das eine Anpassung von OPNsense (oder von HardenedBSD) und welche anderen Besonderheiten des PF müssen beachtet werden?

Das ist korrekt, das FreeBSD Handbuch beschreibt das richtig. Bzw. ist das die Art, in der PF arbeitet, egal ob Open- oder FreeBSD. Um das vollständig zu begreifen, solltest du bei Interesse ggf. eine Doku zu PF lesen. Kurz gefasst gibt es in der PF Syntax verschiedene Begriffe beim Bau einer Regel. Einer ist der Begriff "QUICK". Eine Quick Regel wird bei passendem Paket _sofort_ ausgeführt. Da OPN/pfSense beide solche Quick Regeln erstellen, ist es aber ebenso korrekt, was beide Projekte schreiben: first rule matches. Wo man das selbst sehen/einstellen könnte (sollte man nur in besonderen Fällen) sind die Floating Regeln. Hier kann man tatsächlich beim Erstellen auswählen ob die Regel "Quick" ist oder nicht. Wären die Regeln es nicht, wären lange Regelwerke aber extrem chaotisch, da durch breitere oder schmalere Nennung von IPs oder IP Netzen ein Paket beim Durchlaufen mehrfach den Status ändern würde und man dann "von hinten" suchen müsste, auf welche Regel ein Paket zutrifft.

>- Eine frisch installierte OPNsense hat gemäss GUI keine aktiven Regeln an der WAN Schnittstelle, per default würde alles geblockt, was nicht explizit erlaubt sei. Diese default Drop-Regel sehe ich nirgends im GUI, ebenso wenig wie Pass-Regeln vom WAN zum LAN für Traffic mit Status established oder related. Die müssten aber da sein, schliesslich kann ich mit einem client der OPNsense im Internet surfen. Es gibt also (sinnvolle) default Regeln, die im GUI nicht sichtbar sind. Kann ich das im GUI ändern oder wo kann ich sie stattdessen sehen?

Beide Sensen legen in ihrem PF Regelwerk eine "block any" Regel zu Grunde, die ohne ein Quick ganz am Anfang steht. Passt also keine andere Quick Regel, greift immer die Block Any Regel zu Beginn. Das ist in beiden Projekten beschrieben und ist somit "Standard" Verhalten. Das muss dann m.E. nicht noch extra in der Oberfläche angezeigt werden. Ebenso werden u.a. andere Helfer Regeln, die bspw. für lokale Dienste o.ä. nötig sind angezeigt, da dies alle Einsteiger komplett verwirren würde und die Gefahr groß ist, dass das jemand dann aus Versehen verändert und damit Kernfunktionen beschädigt.
WAN Regeln für "established" gibt es keine, was du mit "related" meinst ist mir nicht klar. Die Funktion eines Stateful Filters ist dir aber bekannt?

Grüße Jens

[stoe]

Hallo Jens

Danke für Deine ausführliche und verständliche Antwort, leuchtet mir alles ein. An die quick rules hab ich gar nicht gedacht...

Nur Dein letzter Absatz verwirrt mich, wohl weil ich pf noch zu wenig kenne bzw. noch in iptables denke. Hab mir jetzt mal das Book of pf gekauft.

In iptables regle ich am WAN folgendes ausdrücklich:

• Lass alle Antworten auf im LAN initiierte Anfragen (-> session hat state established) durch;
• Lass allen traffic durch, der mit einer bestehenden Session in Verbindung steht, z. B.  den Datenkanal bei aktivem FTP (-> state related);
• Lass traffic durch, der zwar nicht im LAN initiiert worden ist (-> state new), für den aber eine ausdrückliche Pass-Regel besteht, z. B.  für ssh (Protokoll und Port müssen stimmen)
• Lass hier am WAN Interface sonst nichts rein.

In OPNsense sind Regeln 1, 2 und 4 wohl per default ebenso gesetzt. Wenn ich im GUI neue Regeln definieren will, habe ich aber kein Feld zur Angabe des Status gefunden. Bin grad unterwegs und kann das von hier nicht prüfen, sorry. Vielleicht täusche ich mich ja

Meine Frage war nun, wie ich z. B.  Regel 1 in OPNsense selber formulieren müsste, wenn sie nicht schon vorhanden wäre.

Danke & Gruss
stö

[JeGr]

IPtables ist da nicht mit PF zu vergleichen. Ganz andere Ausganssituation

> Lass alle Antworten auf im LAN initiierte Anfragen (-> session hat state established) durch;

Das ist unnötig, PF ist stateful und erkennt Antworten auf einen initiierten State selbständig. Reinlassen von Paketen einer ausgehenden erlaubten Sitzung ist unnötig.

> Lass allen traffic durch, der mit einer bestehenden Session in Verbindung steht, z. B.  den Datenkanal bei aktivem FTP (-> state related);

Das sind zwei Sachen in einen vermascht. FTP ist ein sehr schlechtes Beispiel. FTP benötigt technisch gesehen eigentlich einen Proxy um sowas zu erkennen - zumindest aktives FTP mit einkommendem Datenkanal. Dass IPTables das macht, ist genau der ersten Aussage zuzuschreiben. Da wird mit DarkMagicTM eben noch ein bisschen Proxy hier und ein bisschen gemauschel da gemacht, das ist zwar ganz nett, aber technisch nicht unbedingt ein Job des Paketfilters der darüber gar keine Ahnung hat / haben sollte. Alles andere ist wie bei 1) stateful traffic und daher erlaubt.

> Lass traffic durch, der zwar nicht im LAN initiiert worden ist (-> state new), für den aber eine ausdrückliche Pass-Regel besteht, z. B.  für ssh (Protokoll und Port müssen stimmen)

Das sind ganz normale WAN Regeln auf dem Interface.

> Lass hier am WAN Interface sonst nichts rein.

Das ist implizit da default.

> Wenn ich im GUI neue Regeln definieren will, habe ich aber kein Feld zur Angabe des Status gefunden.

Es gibt keinen. Wie gesagt ist die Unterscheidung nicht sinnvoll, da teils gar nicht Job des Paketfilters. Gefiltert wird - und das ist m.E.n. auch so dokumentiert - nur der initiale Verbindungsaufbau, also das erste Paket einer Verbindung. Alles andere wird als State angelegt und durch Stateful Inspection erlaubt und durchgewunken, um nicht unnötig Zeit beim Durchlaufen der Filter-Queue bzw. der Regeltabelle zu benötigen.

> Meine Frage war nun, wie ich z. B.  Regel 1 in OPNsense selber formulieren müsste, wenn sie nicht schon vorhanden wäre.

Wie schon gesagt: gar nicht, weil du das nicht zu tun hast. Für Antwortpakete AUF eine legitime Verbindung ist Stateful Inspection zuständig, nicht irgendeine Regel. Wäre es nicht so, wäre der Filter wesentlich stärker belastet und würde höhere Hardware Anforderungen benötigen, da jedes einzelne Paket jeden Moment durch die komplette Filter Queue laufen müsste nur um nachzusehen ob es auch wirklich wirklich durchgelassen werden soll.

Deine Unterscheidung zwischen 1/2 ist meines Wissens (ist ein wenig her dass ich mich mit IPTables rumschlagen musste) auch nicht ganz richtig. Established steht m.W. für Verbindungen, die die aktuelle IPTables Sitzung mit "new" gestartet hat - also Stateful Antworten - sowie von Verbindungen die vorher existiert haben (vor einem Neustart des Filters bspw.). Der State Related ist m.W. bezogen auf andere Protokolle wie bspw. ICMP, die Antwortpakete in anderem Format senden als die Frage (ICMP Type 0 / Type 6 - echo request und reply z.B.) womit dann die Antworten der vorherigen Frage quasi zugeordnet werden.

PF wickelt diese Dinge alle unter dem Key "keep state" in der Regel ab, die die Verbindung nach außen erlaubt hat. Ein

pass in quick on $lan_if inet proto icmp from $lan_net to any icmp-type echoreq keep state

kümmert sich um genau das. Es gibt zwar kein "keep state" in der Theorie für ICMP oder UDP, PF simuliert dies aber entsprechend, indem es auf Echoreq Anfragen vom IF die zugehörigen Echoreply Antworten zu dem IF zurück durchstellt. Bei UDP ist es ähnlich, hier gibt es zwar vom Ziel kein Handshake oder sonstwelche Antworten, aber der "keep state" sorgt hier einfach dafür, dass die zugehörigen weiteren UDP Pakete der Session direkt durchgewunken werden ohne nochmal durch das komplette Filterprocessing zu müssen.

PF filtert immer(meist) nur den Verbindungsaufbau, also den SYN, alles andere gibt man via keep state und flag filtering dann in den stateful Filter.

Die Sensen nehmen dir ansonsten nur noch zusätzlich das Erstellen der einzelnen "pass out" Regel ab. Theoretisch müsstest du jedes "pass in" auf einem Interface durch ein "pass out" auf dem gewünschten outbound Interface ergänzen. Das legen die Sensen aber selbständig an, damit die User nicht komplett durcheinander kommen und wild auf LAN/WAN irgendwelchen falschen Regeln anlegen

Grüße
Jens

[stoe]

Gut, dass ich gefragt habe.

Vielen Dank, Jens, für die Erhellung. Du hast damit meine Fragen beantwortet.

Da liegt mein persönlicher Hund begraben:

Gefiltert wird - und das ist m.E.n. auch so dokumentiert - nur der initiale Verbindungsaufbau, also das erste Paket einer Verbindung. Alles andere wird als State angelegt und durch Stateful Inspection erlaubt

Ich hab diese Dokumentation so noch nicht gefunden, aber Deine Antwort erklärt mir den relevanten Unterschied zwischen iptables und pf. "stateful" bedeutet demnach in pf, dass der Filter "Antworten auf einen initiierten State selbständig" erkennt, während es in iptables bedeutet, dass ich den Status der Verbindung als Filterkriterium angeben kann/muss.

Ich werd mich nun noch ein bisschen mit dem "keep state" beschäftigen (ist für mich ebenso noch "DarkMagicTM", v.a. wenn "PF simuliert ..."), aber das mindset ist mir nun eigentlich klar.

Besten Dank und Gruss
stö

[JeGr]

Kein Problem. Es ist ja an der Stelle in beiden Implementationen Stateful Filtering vom Grundgedanken. Nur dass du in IPTables es explizit definieren musst und es in PF einfacher bereits erlaubt ist (weil es ansonsten kaum Sinn machen würde, State Tracking zu aktivieren ).

Vom Prinzip der Vereinfachung der GUI vs. den Grundregeln gibt es einiges, was du manuell über die advanced options abschalten kannst (automatisches Anlegen von XY Regeln...) wenn man wirklich alles händisch selbst kontrollieren will. Der große Unterschied im Gegensatz dazu, PF manuell zu schreiben und die Sensen zu nutzen ist, dass sie (als Standard) nur eingehenden Traffic auf einem Interface betrachten und dafür Regeln bauen (Ausnahme: Floating, da könnte man noch mehr definieren). Bei PF selbst müsste man dazu die Kommunikationsbeziehung genau betrachten und bspw. sagen, dass du ausgehend SSH von LAN->WAN haben willst, aber bspw. kein SSH LAN->DMZ, dann würdest du das schreiben mit "pass in ... on LAN ..." und "pass out ... on WAN ...". Durchs weglassen von einem Pass Out nach DMZ würde das somit nicht erlaubt werden und nur in Richtung WAN dürfen. Bei den Sensen müsstest du das im Filter explizit mit der "Destination NOT DMZ net" bauen, da hier automatisch auf allen anderen Interfaces ein Pass Out gemacht wird um die Regeln in der UI zu vereinfachen.

Aber das ist eben wie an anderer Stelle erwähnt Komfort/UI Handling und Anspruch vs. Funktionalität. Wenn ich als PF Kenner direkt Regelsätze schreiben würde, könnte ich die wahrscheinlich auch kürzer und knackiger packen, aber das ist auch Aufwand und schwerer zu verstehen als eben die UI anzusehen und nur inbound betrachten zu müssen

Grüße