[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)

*Inhalt gelöscht*

 

[toscdesign]

Moment ich bin verwirrt.
Die Outbound NAT Rules erstellt das System doch selbst?

Habe heute blöderweise Updates eingespielt und die neue Version erhalten. Beim Bestätigen des Updates habe ich von diesen ganzen Infos nichts gelesen.
Ich habe auch meine Regeln noch nicht migriert und trotzdem werden sie in den "Rules NEW" angezeigt. Gleichzeitig sind noch ist noch die alte Regel Seite aktiv.

Ich überlege inzwischen mit diesen ganzen Änderungen, ob es nicht mal Sinn ergeben würde, das ganze neu aufzusetzen um alle Altlasten los zu werden.

Edit:
Ich hatte damals den Port für Wireguard (da es sowieso auf der Firewall läuft) nicht per NAT freigegeben sondern per Firewall Rule, das war damals der empfohlene Weg.
Da kann ich ja froh sein das so gemacht zu haben 😅

Edit 2:
Wenn das so weiter geht, suche ich mir vielleicht doch noch ne Alternative zur OpnSense.

 

[BobbyD]

Die Outbound NAT Rules erstellt das System doch selbst?

Die automatischen, ja.

um alle Altlasten los zu werden.

Denke nicht, dass es überhaupt welche gibt oder das nötig wäre.

das war damals der empfohlene Weg.

Das war und ist der Weg.

Wenn das so weiter geht, suche ich mir vielleicht doch noch ne Alternative zur OpnSense.

Kostenlos gibt es doch quasi nichts besseres.

 

[toscdesign]

Warum basteln die eigentlich dauernd dran rum?

 

[besterino]

Weils sonst pfsense wäre?

 

[toscdesign]

Habe heute blöderweise Updates eingespielt und die neue Version erhalten. Beim Bestätigen des Updates habe ich von diesen ganzen Infos nichts gelesen.
Ich habe auch meine Regeln noch nicht migriert und trotzdem werden sie in den "Rules NEW" angezeigt. Gleichzeitig sind noch ist noch die alte Regel Seite aktiv.

Erstmal keine Panik zu dem Thema, jetzt kann ich mich wieder beruhigen.
Gerade eben im opnsense Forum gelesen:

The new rules are populated with old rules read only, they still only exist in the old rules.

Old rules have a distinct command button that opens the legacy rule page, and cannot be deleted/cloned in the new GUI

You still have to migrate eventually.

In 26.7 the old rules will be turned into a plugin, so they will still work. No pressure to migrate yet.

When to migrate to new firewall rules?

When to migrate to new firewall rules?

forum.opnsense.org

 

[Tundor]

Hast du so komplizierte Regeln? Mit dem Assi muss man doch nur exportieren als CSV und wieder importieren, lief bei mir sofort alles prima. War ne Sache von 5 Minuten und vorher halt Snapshot gemacht.

 

[toscdesign]

Meine opnSense Installation ist schon so alt, da gab es noch kein ZFS. Läuft aber auf Proxmovh und wird jede nach per PBS gesichert.

Ne die Regeln sind nicht kompliziert, nur habe ich immer schiss, das ich mir was zerschieße.

 

[Tundor]

Ja ich hab sie auch unter Proxmox laufen, meinte dort einfach nen Snapshot machen und danach halt kurz testen ob noch alles läuft ansonsten zurückspielen.

 

[toscdesign]

Werde ich am Wochenende mal machen.

Beitrag automatisch zusammengeführt: Donnerstag um 19:47

Blöde Frage, ich weiß😅

Wie sieht bei euch eine Regel für die DMZ aus, dass diese nicht auf die anderen Netzerke zugreifen darf.
Ich hatte das früher immer mit einer Regel je Netzwerk.

Würde das aber jetzt mal so ausprobieren wie hier beschrieben, also mit einem Alias der alle IP Ranges der anderen Netzwerke enthält:

How to Create a Basic DMZ (Demilitarized Zone) Network in OPNsense

Going beyond the basics of home networking

homenetworkguy.com

Oder gibt es da eine elegantere Variante?

 

[p4n0]

also mit einem Alias der alle IP Ranges der anderen Netzwerke enthält:

Das ist auch der korrekte Weg.
Die Aliase kannste dann genauso aufs Gaestenetz bzw. alle anderen Netze packen. Wenn ein einzelner Host erreicht werden soll, einfach vor die Block-Rule setzen und fertig.

 

[toscdesign]

Also einen Alias für alle Netze zusammen oder für jedes einen eigenen?

 

[p4n0]

Ein Alias fuer die internen Netze. Evtl. brauchst du nen Allow fuer das jeweilige Netz, weil man sich quasi selbst aussperren wuerde wenn das Netz im Alias innerhalb des gleichen Netzes blockiert wird. Muesste man aber in der Doku nachschauen wie sich die PFSense bei so ner Regel verhaelt. (Oder halt einfach das eigene Netz vor dem Block allowen, dann biste safe).

//edit: Bevor du damit anfaengst am besten nen seperates Emergency Netz konfigurieren, wo du dich anstoepseln kannst. Nur fuer den Fall dass du dich versehentlich aussperrst.
Webgui auf dem Netz logischerweise noch erlauben. Viel Spass beim basteln

 

[toscdesign]

Ein Alias fuer die internen Netze.

👍

Bevor du damit anfaengst am besten nen seperates Emergency Netz konfigurieren, wo du dich anstoepseln kannst.

Hab mir schon überlegt, das Management Netzwerk auf einen eigenen physikalischen Port umzulegen.

Aktuell läuft es mit VLAN1 auf dem gleichen Trunk Port wie die anderen Netze.

Muss dann nur schauen wie ich das mache, denn AccessPoint, Proxmox Host und NPM sind auch in diesem Netz.

Ich greife über firewall.domain.de auf die Opnsense über den NPM zu. Natürlich nur vom internen Netz, von außen gibt's nur Zugriff über den VPN.

 

[BobbyD]

Bei mir ist die Sense ja 'ne VM. Ich baue demnächst wieder um und werde es weiter so handhaben, dass ein eigenständiger Router ein (Management-) LAN bereitstellen wird, damit dieses immer verfügbar ist. Für meinen Desktop heißt das, dass ich eine weitere NIC dafür verwende, ein Gateway wird dieses aber nicht sein.
Praktischerweise ist dieser eigenständige Router auch der AP für einige Wi-Fi-VLANs der Sense.

 

[toscdesign]

Ich will ja netbird mal ausprobieren, daher auch die DMZ um dort den Management Server laufen zu lassen.

 

[toscdesign]

Ein Alias fuer die internen Netze. Evtl. brauchst du nen Allow fuer das jeweilige Netz, weil man sich quasi selbst aussperren wuerde wenn das Netz im Alias innerhalb des gleichen Netzes blockiert wird. Muesste man aber in der Doku nachschauen wie sich die PFSense bei so ner Regel verhaelt. (Oder halt einfach das eigene Netz vor dem Block allowen, dann biste safe).

Das Management Netz hat bei mir aktuell einen "Emergency Port" auf dem Switch, dort kann ich mich notfalls direkt anstöpseln.
Nebenbei setzt die OpnSense automatisch auf diesem Netz eine "Anti Lockut Rule", falls man mal Mist baut.

Ich habe mir jetzt die entsprechenden Aliasse für die Netze angelegt. Dabei habe ich auch direkt gelernt das das angaben von "192.168.0.1/24" eigentlich falsch ist und es "192.168.0.0/24" lauten muss. Die OpnSense korrigert das aber automatisch im Hintergrund, deshalb steht in vielen Guides immer noch "192.168.0.1/24" drin.

Eine Sache kapiere ich immer noch nicht. Wenn ich eine Regel habe die etwas blockieren soll setzte ich die immer auf "Block", trotzdem lese ich immer wieder das man es auf "Pass" + "Invert" setzen soll, das anscheinend das gleiche bewirkt. Verstehe aber nicht was das für. Vorteile bringt? Verwirrt das nicht einfach nur?


Edit:
Warscheinlich habe ich es übertrieben, aber ich habe auch eine Alias Regel für alle Docker Netzwerke erstellt, die ja eigentlich nur intern in Docker laufen sollten.
Overkill, oder gute Idee?

 

[BobbyD]

Overkill, oder gute Idee?

Ehrlich gesagt, keine Ahnung, was Du da treibst.
Die OPNsense erstellt automatisch entsprechende Aliase namens ">interface< network". Was man selbst machen darf, ist einen RFC1918-Alias erstellen, der die drei privaten IPv4-Subnetze enthält. Mit diesem kann man dann einfach alles private IPv4 wegblocken, ohne jedes andere Interface einzeln blocken zu müssen.

 

[AliManali]

Eine Sache kapiere ich immer noch nicht. Wenn ich eine Regel habe die etwas blockieren soll setzte ich die immer auf "Block", trotzdem lese ich immer wieder das man es auf "Pass" + "Invert" setzen soll,

Standardmässig ist bei den Firewall Regeln alles geblockt. Die Regel "allow all" Destination !RFC_1918 liest sich "Erlaube alles, ausser in die privaten Netze". Also das ! invertiert das Ziel.

Musst Du ein paar Seiten weiter zurück blättern, da hatten wir ausgibige Diskussion dazu. Die einen machen noch eine Block All Regel hinten ran.

 

[toscdesign]

Ehrlich gesagt, keine Ahnung, was Du da treibst.

Ein Netzwerk einrichten, das nicht auf die anderen Netzwerke zugreifen darf, sondern nur ins Internetz

Die OPNsense erstellt automatisch entsprechende Aliase namens ">interface< network"

Ich habe mich nach der Info von @p4n0 gerichtet, der nutzt aber wohl eine pfsense wo wie ich das gerade nochmals gelesen habe.
Dort muss man das wohl manuell machen.

Das die OpnSense das automatisch macht... hatte ich vergessen
Nutze das doch schon in den anderen Netzen

Standardmässig ist bei den Firewall Regeln alles geblockt. Die Regel "allow all" Destination !RFC_1918 liest sich "Erlaube alles, ausser in die privaten Netze". Also das ! invertiert das Ziel.

Ok, das kannte ich bis her noch nicht. Ist natürlich die eleganteste Lösung.
Da hätte ich exakt eine Regel die genau das tut was ich will.

Danke

Beitrag automatisch zusammengeführt: Samstag um 13:26

@AliManali
Den Alias "RFC_1918" haste aber selbst angelegt, oder?
Den bekomme ich nämlich nit automatisch in der Auswahl angeboten von der OpnSense.

 

[AliManali]

Ja, der Alias dazu sieht so aus:

 

[toscdesign]

Super danke 👍 Spart einiges an Arbeit und der Alias ist auch übersichtlicher als meiner 😅

Edit:
Sollte so passen:

 

[BobbyD]

@toscdesign Die Regel von Ali ist an sich ok. Aber wenn er nicht noch irgendwo anders was zu diesem Interface geregelt hat, dann können die Server hier DNS nur mit öffentlichen Servern machen, weil ja keinerlei Zugriff auf irgendwelche privaten IPs gegeben ist. Also ein Interface mit nur einer Regel wirst Du eher nicht haben. Neben DNS willst Du in der Regel auch noch NTP lokal machen und auch dort ICMP erlauben.

 

[toscdesign]

Das Netz soll erstmal komplett von den anderen Netzen, meinem DNS usw. entkoppelt sein.
Quasi als wäre es ein eigener Router direkt am Internet.

Daher würde ich ungern "Pass" Regeln zu anderen internen Diensten machen.
Das hier nur öffentliche Server erreichbar sind passt erstmal so weit.

 

[AliManali]

Ja genau. z.B. wenn Du noch Unbound nutzt, musst Du das DNS z.T. noch separat beregeln. Produktiv nutze ich noch normale DNS. Auf meiner Labsense musste ich auch DNS und ICMP beregeln. Wie @BobbyD sagt. Läuft jetzt gerade nicht, kann keinen Screenshot machen.

 

[BobbyD]

Quasi als wäre es ein eigener Router direkt am Internet.

Jain. Es ist so, dass Du am (hoffentlich) "DMZ"-Interface nur regelst, was Hosts aus diesem Interface kommend erreichen dürfen. Aber nicht, was andere Host aus anderen Interfacen dürfen, die dürfen vielleicht durchaus auf dein DMZ-Netz zugreifen.
Ein Router darf zumeist eh alles erreichen, geregelt werden nur die Hosts, die an den Router angeschlossen sind.

Ich erwähne das nur, weil es dir vielleicht noch unklar ist.
Hier gibt es zwei Videos, die das näher beschreiben, falls Bedarf besteht.

 

[toscdesign]

Es ist so, dass Du am (hoffentlich) "DMZ"-Interface nur regelst, was Hosts aus diesem Interface kommend erreichen dürfen.

Ja genau, in den Firewall Regeln vom DMZ Netz stelle ich nur ein was Clients von diesem Netz dürfen bzw. nicht dürfen.

Aber nicht, was andere Host aus anderen Interfacen dürfen, die dürfen vielleicht durchaus auf dein DMZ-Netz zugreifen.

Das stelle ich in den entsprechenden Regeln der anderen Netze ein, ist mir auch klar.


Unabhängig davon habe ich mir jetzt auch Crowdsec eingerichtet um dann später schon bevor es in die DMZ geht zu filtern.
Jetzt muss ich nur noch schauen, welche Blocklists ich subscribe, da im Free Tier max. 3 Stück erlaubt sind.
Ist zwar nicht optimal, aber besser als gar kein Schutz für die DMZ.

 

[AliManali]

Nutze für Crowdsec einen eigens errichteten "honeypot". Sprich eine NAT Regel, die nirgends hin zeigt und loggt. Wenn da jemand auf einem bösen Port anklopft, geht er gleich mal für 72h ins Crowdsec Jail. Dafür funktionieren die Community Regeln nicht mehr, die habe ich irgendwie abgeschossen. Muss ich dann nochmals in Angriff nehmen, nachdem ich dann das Netzwerk komplett neu gemacht habe. Werde dann einfach die SSD von der Lab- und der Produktivsense quertauschen.

Als Community Liste habe ich abuseipdb.com genommen. Aber wie gesagt die funktioniert atm nicht, habe ich irgendwie verkonfiguriert per SSH. Aber der honeypot ist eh viel besser...

 

[toscdesign]

Als Community Liste habe ich abuseipdb.com genommen. Aber wie gesagt die funktioniert atm nicht, habe ich irgendwie verkonfiguriert per SSH. Aber der honeypot ist eh viel besser...

Hast du das nicht per offiziellem OpnSense Plugin installiert?

 

[AliManali]

Ja, schon mit dem offiziellen Crowdsec Plugin von der Sense. Aber das musst Du ja mit Community Listen füttern. Hatte da wie gesagt erst mal abuseipdb.com genommen.

Das mit dem honeypot hatte ich mit Hilfe von KI irgendwie hin gebogen. Erst einen Alias angelegt mit den "verbotenen" Ports, und dann eine WAN FW Regel angelegt, die nirgends hin zeigt, blockt und loggt. Um das mit Crowdsec zu vernüpfen, musst Du aber per SSH rum basteln. Frag mich jetzt nicht wie, war da ellenlang mit beschäftigt, bis das funktioniert hat. Einfach die KI fragen, die hilft dir da sicher gerne weiter.

 

[BobbyD]

@toscdesign Q-Feeds kannst Du dir angucken und firehol_level1. Crowdsec bringt eher wenig im free tier.