12
Floating Rules bei OPNsense
Hallo Forum,
ich traue mich gar nicht zu fragen, aber meine Unruhe überwiegt, weshalb ich es riskiere gesteinigt zu werden.
Es geht bei der OPNsense um die Firewall-Regeln.
Die läuft derzeit ohne große Einstellungen und Besonderheiten wie folgt:
- WAN für eine PPPOE-Einwahl
- LAN Interface mit statischer IP
- DHCP Server für LAN
- Unbound DNS Server im LAN
Auf Grund dessen, dass ich keine speziellen Änderungen vorgenommen habe, sind auch die Regeln noch im "Standard".
Laut Dokumentation wird alles aus dem LAN ausgehend erlaubt (somit kompletter Datenverkehr) und alles was auf das WAN läuft, wird geblockt. Ich bin also bis dato von einem geschlossenen Scheunentor ausgegangen...
... bis ich die floating rules gesehen habe. Hier ein paar Bilder aus den Regeln.
Mich machen die Regeln auf dem WAN Interface echt nervös.
1) Warum wurden diese automatisch erstellt?
2) Sind diese Regeln für den Betrieb in der Form notwendig?
Grundsätzlich sollen keine Dienste oder Verbindungen von Außen nach Innen kommen. Der interne Datenverkehr ist zwar im Moment offen, soll aber auch noch reglementiert werden. Aber jetzt geht es mir erstmal um die Basics.
Ist schon wieder viel mehr Text geworden als erhofft.
Ich danke euch für eure Antworten im Voraus.
Sonnige Grüße
ich traue mich gar nicht zu fragen, aber meine Unruhe überwiegt, weshalb ich es riskiere gesteinigt zu werden.
Es geht bei der OPNsense um die Firewall-Regeln.
Die läuft derzeit ohne große Einstellungen und Besonderheiten wie folgt:
- WAN für eine PPPOE-Einwahl
- LAN Interface mit statischer IP
- DHCP Server für LAN
- Unbound DNS Server im LAN
Auf Grund dessen, dass ich keine speziellen Änderungen vorgenommen habe, sind auch die Regeln noch im "Standard".
Laut Dokumentation wird alles aus dem LAN ausgehend erlaubt (somit kompletter Datenverkehr) und alles was auf das WAN läuft, wird geblockt. Ich bin also bis dato von einem geschlossenen Scheunentor ausgegangen...
... bis ich die floating rules gesehen habe. Hier ein paar Bilder aus den Regeln.
Mich machen die Regeln auf dem WAN Interface echt nervös.
1) Warum wurden diese automatisch erstellt?
2) Sind diese Regeln für den Betrieb in der Form notwendig?
Grundsätzlich sollen keine Dienste oder Verbindungen von Außen nach Innen kommen. Der interne Datenverkehr ist zwar im Moment offen, soll aber auch noch reglementiert werden. Aber jetzt geht es mir erstmal um die Basics.
Ist schon wieder viel mehr Text geworden als erhofft.
Ich danke euch für eure Antworten im Voraus.
Sonnige Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 7569557798
Url: https://administrator.de/contentid/7569557798
Printed on: May 3, 2024 at 07:05 o'clock
12 Comments
Latest comment
Hallo,
diese Regeln sind ja kommentiert. Mit welcher Regel hast Du denn ein Problem? Mit den „Block“-Regeln ja eher nicht. Und die anderen geben hauptsächlich Datenverkehr frei, den die Firewall selbst, z.B. für Firmwareupdates benötigt.
Am Besten wäre es, Du gehst jede Regel durch und überlegst was die Regel macht:
Grüße
lcer
diese Regeln sind ja kommentiert. Mit welcher Regel hast Du denn ein Problem? Mit den „Block“-Regeln ja eher nicht. Und die anderen geben hauptsächlich Datenverkehr frei, den die Firewall selbst, z.B. für Firmwareupdates benötigt.
Am Besten wäre es, Du gehst jede Regel durch und überlegst was die Regel macht:
- im welche Quellen und Ziele handelt es sich?
- welche Dienste werden erlaubt bzw. verboten.
Grüße
lcer
1
Moin moin,
ein "Problem" habe ich tatsächlich nur mit denen, die unter WAN zu finden sind.
Ich habe deinen Vorschlag direkt mal in die Tat umgesetzt und bin ich die Regeln einmal durchgegangen.
Da ich DHCP und DNS aktiviert habe, verstehe ich die notwendigen Regeln auf dem LAN-Interface.
Mir erklärt sich jedoch nicht, warum diese auch auf das WAN-Interface angewendet werden.
Parallel bin ich nun auch dahinter gekommen, dass sich die Floating Rules bzw. die automatisch generierten Regeln, sich nicht löschen lassen. Das schmeißt mich jetzt völlig aus der Bahn...
Am liebsten wäre es mir, die Floating Rules komplett über Board zu werfen, selbst wenn es das bedeutet, dass ich für ein OPNsense-Update temporär was aufbohren muss.
Viele Grüße
ein "Problem" habe ich tatsächlich nur mit denen, die unter WAN zu finden sind.
Ich habe deinen Vorschlag direkt mal in die Tat umgesetzt und bin ich die Regeln einmal durchgegangen.
Da ich DHCP und DNS aktiviert habe, verstehe ich die notwendigen Regeln auf dem LAN-Interface.
Mir erklärt sich jedoch nicht, warum diese auch auf das WAN-Interface angewendet werden.
Parallel bin ich nun auch dahinter gekommen, dass sich die Floating Rules bzw. die automatisch generierten Regeln, sich nicht löschen lassen. Das schmeißt mich jetzt völlig aus der Bahn...
Am liebsten wäre es mir, die Floating Rules komplett über Board zu werfen, selbst wenn es das bedeutet, dass ich für ein OPNsense-Update temporär was aufbohren muss.
Viele Grüße
Hallo,
Grüße
lcer
Zitat von @simple198:
Moin moin,
ein "Problem" habe ich tatsächlich nur mit denen, die unter WAN zu finden sind.
Ich habe deinen Vorschlag direkt mal in die Tat umgesetzt und bin ich die Regeln einmal durchgegangen.
Da ich DHCP und DNS aktiviert habe, verstehe ich die notwendigen Regeln auf dem LAN-Interface.
Mir erklärt sich jedoch nicht, warum diese auch auf das WAN-Interface angewendet werden.
Parallel bin ich nun auch dahinter gekommen, dass sich die Floating Rules bzw. die automatisch generierten Regeln, sich nicht löschen lassen. Das schmeißt mich jetzt völlig aus der Bahn...
Am liebsten wäre es mir, die Floating Rules komplett über Board zu werfen, selbst wenn es das bedeutet, dass ich für ein OPNsense-Update temporär was aufbohren muss.
lieber nicht. Ich kann Dir irgendwie nicht folgen. Dir Ist schon klar, dass das rote Kreuz bedeutet, dass der Verkehr blockiert wird. Schreib Doch mal ein konkretes Beispiel, welche Regel Dir ein Dorn im Auge ist.Moin moin,
ein "Problem" habe ich tatsächlich nur mit denen, die unter WAN zu finden sind.
Ich habe deinen Vorschlag direkt mal in die Tat umgesetzt und bin ich die Regeln einmal durchgegangen.
Da ich DHCP und DNS aktiviert habe, verstehe ich die notwendigen Regeln auf dem LAN-Interface.
Mir erklärt sich jedoch nicht, warum diese auch auf das WAN-Interface angewendet werden.
Parallel bin ich nun auch dahinter gekommen, dass sich die Floating Rules bzw. die automatisch generierten Regeln, sich nicht löschen lassen. Das schmeißt mich jetzt völlig aus der Bahn...
Am liebsten wäre es mir, die Floating Rules komplett über Board zu werfen, selbst wenn es das bedeutet, dass ich für ein OPNsense-Update temporär was aufbohren muss.
Grüße
lcer
Nehmen wir die 1, 3, 4,5 und 6. Alle sind zwar IPv6 (bin ich noch nicht sattelfest mit), aber lassen "Informationen" über ICMP raus...
Dann die letzten beiden Rules. CARP. Da habe ich nicht mal was konfiguriert...
Hallo,
Wenn Du Dich mit Firewallregeln beschäftigen willst, musst Du Dich zwangsläufig auch mit den verschiedenen Netzwerk-Protokollen beschäftigen. Sonst erleidest Du Schiffbruch.
Grüße
lcer
Zitat von @simple198:
Nehmen wir die 1, 3, 4,5 und 6. Alle sind zwar IPv6 (bin ich noch nicht sattelfest mit), aber lassen "Informationen" über ICMP raus...
Nehmen wir die 1, 3, 4,5 und 6. Alle sind zwar IPv6 (bin ich noch nicht sattelfest mit), aber lassen "Informationen" über ICMP raus...
- und was bitte? ICMP!
- und wohin? in angeschlossene Netzwerksegment
Dann die letzten beiden Rules. CARP. Da habe ich nicht mal was konfiguriert...
Carp ist das Protokoll für Redundanz mit mehrern OPNSenses. siehe https://docs.opnsense.org/manual/how-tos/carp.html- wohin? Multicast-Adresse. Das machen die meisten Netzwerkgeräte (Router, Switche). Das kann man aber sicher abschalten - dort wo CARP konfiguriert ist.
Wenn Du Dich mit Firewallregeln beschäftigen willst, musst Du Dich zwangsläufig auch mit den verschiedenen Netzwerk-Protokollen beschäftigen. Sonst erleidest Du Schiffbruch.
Grüße
lcer
1Wenn Du Dich mit Firewallregeln beschäftigen willst, musst Du Dich zwangsläufig auch mit den verschiedenen Netzwerk-Protokollen beschäftigen. Sonst erleidest Du Schiffbruch.
Ja, absolut!
Bin dran...* wohin? Multicast-Adresse. Das machen die meisten Netzwerkgeräte (Router, Switche). Das kann man aber sicher abschalten - dort wo CARP konfiguriert ist.
Jap, auf dem Link war ich auch schon... Spannende Sache, aber absolut im Moment nicht relevant für mich, weshalb ich mich wunder, dass es hier eine Regel gibt. Aktiviert oder Deaktiviert habe ich in der Richtung nicht.
Mit anderen Worten: Die Regeln sind deines Erachtens nach in Ordnung?
Gibt es denn grundsätzlich die Möglichkeit, diese Regeln aufzuräumen? Rein zum Testen würde mich das interessieren, dann kann ich direkt nachvollziehen was nicht klappt, wenn Regel X deaktiviert oder gelöscht wurde.
Danke für deine Geduld!
Hallo,
OK. Die ICMP-Regeln hast also verstanden. Schön!
Jap, auf dem Link war ich auch schon... Spannende Sache, aber absolut im Moment nicht relevant für mich, weshalb ich mich wunder, dass es hier eine Regel gibt. Aktiviert oder Deaktiviert habe ich in der Richtung nicht.
Ich habe gerade keine OPNSense zur Hand. Die Regeln ermöglichen das CARP-HA-Feature der OPNSense. Du musst schauen, ob Du das Feature deaktivieren kannst. Die OPNSense ist ormalerweise so gestrickt, dass Regeln bei deaktiviertem Feature verschwinden.
Stelle mindestens sicher, dass Du keine Regeln erstellst/änderst, die das Interface bestreffen, über das Du konfigurierst. Dazu sollte man ein separates Admin-Interface erstellen.
Grüße
lcer
OK. Die ICMP-Regeln hast also verstanden. Schön!
* wohin? Multicast-Adresse. Das machen die meisten Netzwerkgeräte (Router, Switche). Das kann man aber sicher abschalten - dort wo CARP konfiguriert ist.
Jap, auf dem Link war ich auch schon... Spannende Sache, aber absolut im Moment nicht relevant für mich, weshalb ich mich wunder, dass es hier eine Regel gibt. Aktiviert oder Deaktiviert habe ich in der Richtung nicht.
Mit anderen Worten: Die Regeln sind deines Erachtens nach in Ordnung?
Mit anderen Worten: Dein Unwissen im Bereich Netzwerkprotokolle ist ein höheres Risiko als diese aktivierten Regeln.Gibt es denn grundsätzlich die Möglichkeit, diese Regeln aufzuräumen? Rein zum Testen würde mich das interessieren, dann kann ich direkt nachvollziehen was nicht klappt, wenn Regel X deaktiviert oder gelöscht wurde.
Sei vorsichtig beim Testen. Wenn Du Dich aussperrst kann es sein, das das nicht wieder rückgängig machen kannst. Grundsätzlich sollte man, wenn man an einer Firewall bastelt wissen, wie man sich im Notfall per seriellem Terminal auf die Firewall schalten kann. Ausserdem sollte man die Kommandozeilenbefehle (CLI) von OPNSense sowie dei Basics von BSD beherrschen. Sowie sollte man mit der Verwendung von vi vertraut sein.Stelle mindestens sicher, dass Du keine Regeln erstellst/änderst, die das Interface bestreffen, über das Du konfigurierst. Dazu sollte man ein separates Admin-Interface erstellen.
Grüße
lcer
Es würde auch den Rahmen eines Forums sprengen wenn man dir jetzt den Sinn und Unsinn von IPv4 und v6 Protokoll Management Traffic (ICMP bzw. ICMPv6) und das ganz besonders bei IPv6 grundlegend erklären müsste. Das kann ein kleines bisschen Grundlagen Lektüre sicher deutlich besser.
https://danrl.com/ipv6/
CARP bzw. dessen Multicast Traffic ist z.B. zwingend erforderlich für ein Firewall HA Design und MC wird im Internet gar nicht geroutet. Desweiteren werden dort automatische Regeln erstellt wenn du z.B. den VPN Zugang erlaubst. (Regel Automatismus ist im Grundsetup einstellbar!)
Der Rest ist auch selbsterklärend wenn man das Regelwerk einmal genau ansieht was die Firewall passieren lässt. Deciso B.V. würde auch sicher keine löchrige Firewall auf die Community loslassen ohne selbst gesteinigt zu werden.
Ist alles also was zwingend fürs Protokoll und Dienstehandling im Default erforderlich ist, aber keinerlei Sicherheitsproblem darstellt.
Kollege @lcer00 hat es oben ja schon auf den Punkt gebracht: "musst Du Dich zwangsläufig auch mit den verschiedenen Netzwerk-Protokollen beschäftigen." Besonders zur Thematik ICMPv6 solltest du die o.a. Lektüre lesen...und verstehen!
Mal ehrlich und ohne Steine: Solche simplen Protokoll Binsenweisheiten sollte man als gestandener IT Consultant aber eigentlich kennen wenn man seinen Kunden gegenübertritt. 🧐
https://danrl.com/ipv6/
CARP bzw. dessen Multicast Traffic ist z.B. zwingend erforderlich für ein Firewall HA Design und MC wird im Internet gar nicht geroutet. Desweiteren werden dort automatische Regeln erstellt wenn du z.B. den VPN Zugang erlaubst. (Regel Automatismus ist im Grundsetup einstellbar!)
Der Rest ist auch selbsterklärend wenn man das Regelwerk einmal genau ansieht was die Firewall passieren lässt. Deciso B.V. würde auch sicher keine löchrige Firewall auf die Community loslassen ohne selbst gesteinigt zu werden.
Ist alles also was zwingend fürs Protokoll und Dienstehandling im Default erforderlich ist, aber keinerlei Sicherheitsproblem darstellt.
Gibt es denn grundsätzlich die Möglichkeit, diese Regeln aufzuräumen?
Ja, indem du sie VORHER entsprechend customized wenn du sie nicht löschen kannst. Du kennst als FW Profi die Firewall Grundregel: "First match wins" zum Ruleset ja auch. Kollege @lcer00 hat es oben ja schon auf den Punkt gebracht: "musst Du Dich zwangsläufig auch mit den verschiedenen Netzwerk-Protokollen beschäftigen." Besonders zur Thematik ICMPv6 solltest du die o.a. Lektüre lesen...und verstehen!
Mal ehrlich und ohne Steine: Solche simplen Protokoll Binsenweisheiten sollte man als gestandener IT Consultant aber eigentlich kennen wenn man seinen Kunden gegenübertritt. 🧐
Mit anderen Worten: Dein Unwissen im Bereich Netzwerkprotokolle ist ein höheres Risiko als diese aktivierten Regeln.
Genauso hätte ich das an deiner Stelle auch ausgedrückt. 😅 Passt für mich!Sei vorsichtig beim Testen
Stelle mindestens sicher, dass Du keine Regeln erstellst/änderst, die das Interface bestreffen, über das Du konfigurierst. Dazu sollte man ein separates Admin-Interface erstellen.
Absolut. Die Kiste läuft noch als VM. Ich kann also jederzeit wieder zurück bzw. in zweifelfall setzte ich das System einfach neu auf. So viel habe ich hier im Netzwerk noch nicht was konfiguriert werden muss. Mal abgesehen davon lerne ich dann die Schritte wieder... 🤞 Es würde auch den Rahmen eines Forums sprengen wenn man dir jetzt den Sinn und Unsinn von IPv4 und v6 Protokoll Management Traffic (ICMP bzw. ICMPv6) und das ganz besonders bei IPv6 grundlegend erklären müsste.
Bitte nicht! ein Forum sehe ich als Hilfe zur Selbsthilfe an. Weder ihr dürft Lektüre nochmal her unterschreiben, noch will ich etwas "fertiges" ohne Background genannt bekommen. (Regel Automatismus ist im Grundsetup einstellbar!)
Verflixt! Wo? Ich habe auf Anraten in Tutorials den Wizard übersprungen. Fehler?Ja, indem du sie VORHER entsprechend customized wenn du sie nicht löschen kannst. Du kennst als FW Profi die Firewall Grundregel: "First match wins" zum Ruleset ja auch. face-wink
Ich glaube ich verstehe dich falsch mit dem "Vorher". Ja, die OPNsense will ich an meine Bedürfnisse anpassen. Ja, wenn die automatisch erstellten Regel notwendig sind, auch ok. Aber kann man das automatisch Erstellen abschalten?Mal ehrlich und ohne Steine: Solche simplen Protokoll Binsenweisheiten sollte man als gestandener IT Consultant aber eigentlich kennen wenn man seinen Kunden gegenübertritt. 🧐
Nicht zu weit werfen! Hoffe du warst kein guter Sportler bei den Bundesjugendspielen. 😝 Betrachtet man die berufliche Seite, so würde ich mir niemals anmaßen einem Kunden Dienstleistungen in Themen anzubieten, die ich nicht beherrsche. Mit dieser Ansicht, definiere ich auch den Consultant. Somit muss ein "Berater" nicht von jedem Thema 100%ig Ahnung haben, sondert bildet eben (auch) die Schnittstelle zwischen Kunden und Fachbereichen.
Hoffe du warst kein guter Sportler bei den Bundesjugendspielen
Leider doch! Irgendwo im Dokumentenordner sind noch unzählige Urkunden mit denen man die Wand tapezieren kann. 🤣Mit "vorher" war das Customizing dieser Rules mit einer höheren Priority (Reihenfolge) gemeint. Dies Regelwerk wird dann immer VOR den automatisch erstellten oder floatings abgearbeitet die diese dann ignorieren.
Verflixt! Wo?
In den Advanced Settings die man immer in aller Ruhe durchgehen sollte wenn man den Wizzard überspringt (der übrigens nur ganz banale Grundsettings abfragt und nichts verschlimmbessert wie bei MS)!!Da sind dann auch so Dinge wie das unsinnige Gateway Monitoring abschalten und das lokal gerouteter Traffic NICHT durch die FW laufen soll. DHCP bitte local Time statt UTC verwendet und wenn man wie du eine VM nutzt kann es sinnvoll sein das HW Offloading der NICs zu deaktivieren sollte dein Hypervisor NIC Treiber sowas nicht supporten. AES/NI durchreichen auf die VM und und und...
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat. ...
Wenn du wirklich an die auto und float Rules Hand anlegen willst kannst du das immer über den Shell Zugang erreichen:
https://forum.opnsense.org/index.php?topic=15754.0
Moin,
Vielen Dank und einen schönen Tag noch!
Mit "vorher" war das Customizing dieser Rules mit einer höheren Priority (Reihenfolge) gemeint. Dies Regelwerk wird dann immer VOR den automatisch erstellten oder floatings abgearbeitet die diese dann ignorieren.
Ok, das erklärt sich. Ich habe mich bisher immer an der "Processing order" orientiert und stolperte daher über deine Aussage.Wenn du wirklich an die auto und float Rules Hand...
Dein "wirklich" lässt mich erstmal mit anderen Dingen beschäftigen. ;)Vielen Dank und einen schönen Tag noch!
Dein "wirklich" lässt mich erstmal mit anderen Dingen beschäftigen
Eine weise Entscheidung! 😉
