-
Hallo pfsense Gemeinde,
ich bin vor kurzem von OPNsense nach pfsense gewechselt, da mir die Oberfläche und Handling besser gefällt. Nun musste ich einige Abstriche machen, die mir erst nach dem Wechsel aufgefallen sind, und frage deswegen nach einigen Updates:-
Zenarmor: ich weiß das es da Streitigkeiten zwischen Zenarmor und Netgate gibt, gibt es da eine Lösung in naher Zukunft? Aktuell musste ich bei Zenarmor auf die Cloud Lösung ausweichen, was ich sehr ungern gemacht habe, zudem musste auch hier einige Abstriche gemacht werden (z.B. lokale Elastic 8, lokaler Mail Server etc.)
-
tcp Syslog: aktuell kann pfsense nicht nativ syslog per tcp senden, nur via syslog-ng. Gibt es da zeitnah eine Lösung?
-
Zabbix client nativ noch immer in der Version 6.4 obwohl schon seit längerem Version 7.x raus ist. Gibt es hier eine zeitnahe Lösung oder Workaround?
Ein Grund von der OPNsense zu wechseln, waren die fixed gesetzten "allow from host itself rules" (und keine Möglichkeit die einfach zu löschen), nun stelle ich fest das die pfsense 2.7.2 diese Rule auch hat, finde diese aber nicht in der floating sektion.
"let out anything IPv4 from firewall host itself (1000009913)"
Kann ich diese bei der pfsense einfach irgendwo löschen oder genauso wie bei der OPNsense nur in den config files?Ich bin für jeden Workaround oder Hinweis dankbar, da ich ungern wieder zur OPNsense zurück möchte.
Grüße Norman
-
-
Update: für das Zabbix Agent 7.x Problem habe ich inzwischen einen Workaround gefunden:
https://www.zabbix.com/de/integrations/pfsense
Funktioniert prima mit dem pfsense Add-On net-snmp
-
@MrEnergy said in Zenarmor, TCP syslog und Zabbix 7.x client, from host itself Rules:
da ich ungern wieder zur OPNsense zurück möchte.
Warum? Du bist vollkommen grundlos gewechselt und solltest dies nun erkennen.
-
ja und nein, das Handling und Layout gefällt mir bei pfsense einfach besser. Aber das waren nicht meine Fragen.
-
J JeGr moved this topic from pfSense German User Group 14 days ago
-
@MrEnergy said in Zenarmor, TCP syslog und Zabbix 7.x client, from host itself Rules:
Ein Grund von der OPNsense zu wechseln, waren die fixed gesetzten "allow from host itself rules" (und keine Möglichkeit die einfach zu löschen), nun stelle ich fest das die pfsense 2.7.2 diese Rule auch hat, finde diese aber nicht in der floating sektion.
Wenn diese Regeln ein Problem für dich sind, hast du leider den Paketfilter und den Ansatz von pfSense/OPNsense nicht verstanden. Die Regeln sind NOTWENDIG für die Funktion der Firewall weshalb diese auch ausgeblendet und nicht bearbeitbar sind, da sie essentiell notwendig sind für die korrekte Funktion.
Ein Paket MUSS für Funktion in PF
- Auf einem Interface in die Firewall EINgehend erlaubt werden
- auf mind. einem anderen Interface der Firewall AUSgehend erlaubt werden
wenn die ausgehenden Regeln fehlen würden, würde jegliche Kommunikation unterbunden werden, da zwar Traffic in die Firewall ein-, aber nicht mehr aus ihr heraus kommen dürfte. Somit kompletter Blockzustand.
Beide -Sense Projekte wie auch M0n0wall davor haben sich zur einfacheren Handhabung und Verständnis der Regeln dazu entschlossen, automatisch ausgenhend aus der Firewall alles zu erlauben um nicht für jeden Regelfall zwei separate Regeln auf zwei Interfaces anlegen zu müssen. Das wäre zwar "extrem sicher" aber auch extrem umständlich und würde die meisten Umsteiger von anderen Firewall sehr irritieren, da kein anderer Hersteller hier in den Defaults ein- und ausgehende Regeln pro Verbindung benötigt.
Ausgehend bezieht sich hier NICHT auf "Traffic in Richtung Internet", sondern es geht hier explizit um den Weg
---> Interface 1 (eingehend) ---> Firewall ---> Interface 2,3,4 (ausgehend) --->
den die Pakete beim passieren der Firewall beschreiten. Daher gehe ich stark davon aus, dass dir schlicht die Regellogik von pf nicht bekannt ist und man deshalb Regeln abschalten will. Das wäre in diesem Fall aber komplett unangebracht. Da man in pfSense keine ausgehenden Regeln außer als Floating Regeln definieren kann, wäre es zudem sehr sinnfrei, die ausgehenden Regeln selbst definieren zu wollen, da man diese dann nur auf dem Floating Interface definieren könnte und dann einen Bruch in der Regellogik hat.
TL;DR
Es macht keinen Sinn :)Cheers
-
danke für deine ausführliche Erklärung und warum vorgesetzte Regelwerke für dich Sinn machen.
Und natürlich kenne ich die Regellogik (seit über 30 Jahren nun schon).
Selbst komme ich von Firewalls wie von Fortinet, Cisco, Juniper und Check Point. Und genau, das war mein "Point of Concern", das ich bei den eben genannten Firewalls selbst die Freiheit habe zu entscheiden, welches Regelwerk ich einsetzen möchte, ohne das mir ein bestimmtes Regelwerk vorgesetzt wird, welches ich nicht einfach wieder entfernen kann. Unabhängig davon, ob ich ein bestimmtes Regelwerk benötige für das Management (SSH, HTTP(s)). Dafür könnte man z.B. eben ein bestimmtes Management Interface erstellen, bei dem ersten initialen Setup der pfsense/OPNsense, ohne dabei ein Floating Regelwerk zu erstellen (bzw. vorgesetzt zu bekommen), was direkt alles von Prod/LAN nach WAN erlaubt.
Aber never Mind, inzwischen sind wir wieder auf OPNsense gewechselt, da wir dort einen guten Workaround gefunden hatten, die Standard Floating Rules zu entfernen (welches wir auch ansatzweise bei der pfsense durchführen hätten können). Zudem vermissten wir den 3rd Party Support (e.g. ZenArmor) bei der pfsense.Somit kann diese Post nun geschlossen werden.
-
@MrEnergy said in Zenarmor, TCP syslog und Zabbix 7.x client, from host itself Rules:
Aber never Mind, inzwischen sind wir wieder auf OPNsense gewechselt, da wir dort einen guten Workaround gefunden hatten, die Standard Floating Rules zu entfernen (welches wir auch ansatzweise bei der pfsense durchführen hätten können). Zudem vermissten wir den 3rd Party Support (e.g. ZenArmor) bei der pfsense.
Das macht wie oben beschrieben keinen Sinn. Das hat nichts damit zu tun, dass es "für mich" Sinn macht, sondern mit dem Ziel des Produkts sinnvoll managebar zu sein. Wenn man Regelwerk SO feingranular durchspielen möchte, macht es für mich keinerlei Sinn und Zweck mehr, ein Vorgefertigtes GUI System wie *sense zu nutzen. Wenn man eh alles und jedes kleinste Detail anfassen möchte, wird man damit einfach nicht glücklich. Und mit irgendwelchen Floating Rules etwas "hinzubekommen" was so nicht gedacht ist, schreit schlichtweg "disaster in the making".
Wenn man jede Regel - wie es in PF dann gemacht werden muss - doppelt definieren möchte (eingehend auf einem Interface, ausgehend ggf. auf mehreren Interfaces), macht es m.M.n. nur noch Sinn, sich ein OpenBSD zu greifen und dort ein Ruleset auf sauberem und neuerem PF aufzubauen. Dann kann man gern kontrollieren was man genau tut und wird auch nur das erlaubt haben, was minimum notwendig ist.
ohne dabei ein Floating Regelwerk zu erstellen (bzw. vorgesetzt zu bekommen), was direkt alles von Prod/LAN nach WAN erlaubt.
Die default allow any Regel hat mit in/out Regeln händisch konfigurieren aber nichts zu tun. Der Default der Projekte ist absichtlich so gehalten wie bei den meisten Endgeräten, dass von extern nichts dafür aber von intern erstmal für den ersten Wurf/Test alles geht. Darum packt man auf dieses erste Netz auch sinnvoll sowas wie ein Management drauf, denn dort DARF der Zugriff ja erfolgen - soll er sogar. Alle weiteren Interrfaces sind per default wie WAN deny all. Kein Grund also irgendwelche outbound Regeln manuell definieren zu wollen, denn was ich nicht rein lasse, muss ich auch nicht ausgehend blocken oder ändern. Hier werden auch wieder zwei Tatsachen miteinander vermischt, die m.M.n. nichts miteinander zu tun haben. In den Regelprozess mit outbound Rules einzugreifen hat nichts mit default settings des Zugriffs oder Management Interface zu tun. Die Einzigen Regeln, die ohne Zutun automagisch generiert werden sind welche, die durch Dienste nötig sind sowie einige wenige Standards, die das Schreiben der Regeln vereinfachen - wie eben die pass outs. SSH ist nur offen, wenn konfiguriert. DHCP wird nur erlaubt wenn auch konfiguriert. IPsec wird nur erlaubt wenn konfiguriert. Ich sehe da keinen Widerspruch oder bessere Sicherheit. Ja, es wäre ggf. nett diese Regeln zu sehen. Aber reingrätschen muss ich dafür nicht.
Wenn man ansonsten schon den Kompromiss eingehen will, eine GUI mit den zugehörigen Abstrichen in Detailtiefe etc. mitzunehmen, dann macht es tatsächlich für mich keinen wirklichen Sinn - vor allem wenn das noch jemand verstehen soll, der nicht so tief in der Materie ist - hier die Ein- und Ausgänge durchkonfigurieren zu wollen. Das endet dann oftmals in einem Regelsalat, den ich dann im Support auf den Tisch bekomme von einem armen Kollegen, der damit gestraft ist, etwas zu verstehen, was jemand mit völlig anderen Ansichten als die Distribution sich gedacht hat und das dann "erzwungen" hat. Klar, wenn das für dich allein deine Spielwiese ist - suit yourself, hab Spaß :)
Wenn da aber andere Kollegen mit involviert sind und das ggf. auch noch irgendjemand später übernehmen soll, halte ich das für tatsächlich gefährlicher auf Krampf etwas durchzuziehen nur damit es "gemacht" ist anstatt sich statt dessen bewusst zu sein, was es für pros und contras gibt und diese dann entsprechend mit einzubeziehen wenn man Regeln plant. Denn für die meisten Regelabläufe gibt es keinen großen Nutzen, in- und outbound getrennt zu konfigurieren, nur damit man sich das "pass out any" spart. Für die wenigen Gelegenheiten, in denen man den Traffic absolut gar nicht an irgendeiner Stelle rauskommen lassen möchte, kann man das recht einfach erreichen, die restlichen Male sind mit sinnvoller Regellogik einfacher abgedeckt als mit zwei Regeln kompliziert verbaut.
Und das schreibe ich nicht als kleine persönliche Meinung, sondern als jemand, der "pf" seit seinem Auftauchen in OpenBSD 2.7 in den 90ern eingesetzt und begleitet hat und seitdem in dieser oder jener Form immer wieder am Start hatte. Und als jemand, der heute als Netzwerk Architekt den Fallout von solchen Regelmonstrositäten aufarbeiten muss.Daher meine Warnung gerade eben auch für andere Mitleser, die das auf die Idee bringen könnte, es wäre vllt ja doch hilfreich, die komplette Regellogik zu unterlaufen.
Cheers :)
-
ich gebe Ihnen Recht, was die Einfachheit einer pfsense/OPNsense angeht, um "Regelsalat" zu verhindern.
Und auch verstehe ich Ihren Einwand, das dadurch viele Support-Abfragen reinkommen können. Seinen Sie gewiss, ich habe lang genug Level 1 bis Level 3 Support gemacht.
Es sollte sich grundsätzlich die Frage gestellt werden, für was benötige ich eine Firewall, und was sollte mir die Firewall liefern bzw. schützen.
Und natürlich ist für mich eine Firewall keine Spielwiese, sondern ich weiß was für ein Regelwerk ich benötige und haben möchte, und was nicht.
Gut das ich mit der Meinung von vorgefertigten Floating Rules bei pfsense/OPNsense nicht alleine stehe, und Foren genau mit dem Thema gut gefüllt sind. Zudem sollten man sich fragen, warum etablierte Firewalls wie Fortinet/Juniper, Check Points keine Standard Allow/Floating Rules haben (DENY ALL first), und explizite Management Ports. Zudem ist eine Standard Rule mit DNS/HTTP(s) schnell von LAN to WAN erstellt, und erzeugt kein "Regelwerksalat". Eine DENY ANY ANY Rule am Ende des Regelwerks, die zuerst LOGs erstellt, um zu sehen warum ein Client nicht funktioniert, und die dazu gehörigen Ports dann öffnet (wenn gewünscht), ein Standard Prozedere.
Aber nochmals, ich gehe konform mit Ihnen, das es für den Home User, einfach wie möglich gemacht werden sollte, trotzdem sollte man für erfahrene User die Freiheit geben werden, eine pfsense/OPNsense selbst zu kontrollieren und zu managen. Auch ich sehe kein Problem, eine Abfrage beim Setup einzubringen, ob ich Standard allow floating Rules haben möchte oder nicht und dann eben nur die Management Ports Rule erstellt.
Ich verstehe Ihre Support Sichtweise und wünsche Ihnen und Ihrem Team noch stressfreie Support-Tage.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.