Umbau Netzwerk/Rules

[kosta]

Hallo zusammen,

bin schon seit einigen Wochen dabei mein Netzwerk und Homelab zu Hause umzukrempeln. Alle began mit der Entscheidung VMware aufzulösen und auf Proxmox zu wechseln.
Dabei kam auch die Entscheidung von 192.168.vlan.x/24 zu gehen auf 10.vlan.sortingnetz.x/16.

Damit habe ich die Möglichkeit ein bisschen Ordnung zu halten innerhalb eines Netzes, schon alleine dass ich im LAN 5 logische Bereiche habe. Es Bedarf gewisse Vereinfachung. Etwas weniger Sicherheit aufgrund von Netz-Trennung, aber dafür mehr, weil ich mich dann mehr auf tatsächliche wichtige sicherheitsrelevanten Themen konzentrieren kann, als troubleshooten warum ich jetzt von meinem Handy auf die Steuerung von meinem AVR nicht draufkomme.

Daher habe ich jetzt so eine Basis-Trennung zwischen LAN, PROD (Server), DMZ, Guest... so typisch halt.

Heute habe ich alle Rules gelöscht (tatsächlich ja), Aliases bereinigt, und überall erstmal Any-Any-Any aufgemacht.

Und jetzt überlege ich, was für ein Prinzip bei den Rules gehe ich an.

Meine erste Idee ist "Service-orientiert" zu arbeiten. Also würde ich Aliase erstellen, die bestimmte Ports enthalten, und diese würden dienen eigentlich für bestimmte Ziele nur. Weil service_ad macht Sinn nur am Ziel DC. Aber... wenn ich service_smb nehmen würde, dann kann es durchaus mehr Ziele haben, und ist schon wo ich mich gedanklich verliere.

Ich versuche einfach ein System zu finden, der die Anzahl der Rules übersichtlich hält, oder irgendwie ein System einführen der die Rules irgendwie sortiert, vielleicht logisch trennt.
Ich kenne Kategorien, ich kenne Aliase, ich habe schon einiges gemacht, aber es war immer irgendwie ein Chaos.

In der Arbeit, zum Gegenteil, arbeite ich mit einer Barracuda, und dort gibt es sowohl Sections - also Gruppierungen der Rules, auch im optischen Sinne, wie auch Kaskaden, die zur weiteren Organisation und Optimierung dienen. Barracuda ist allerdings umgekehrt wie OPNsense. OPNsense blockiert ausgehend, so Bedarf das eigentlich ein Umdenken.

Wenn ihr irgendwelche Empfehlungen für mich habt, wäre ich sehr dankbar. Vielleicht paar kurze Beispiele wie ihr die Organisation handhabt.

Anbei so eine schnelle Zeichnung der Idee. Dabei zu beachten dass ich hier nicht zwingend zwischen Floating oder non-Floating unterscheide. Wenn mehrere Netze, ist klarerweise Floating, sonst wenn sich Rule in einem Netz befindet, kann dann mehrere Hosts oder das ganze Netz haben.

Danke euch.

[meyergru]

Hmm. Ich habe hier zwei Fragen:

1. Was heißt "OPNsense blockiert ausgehend, so Bedarf das eigentlich ein Umdenken."? Das ist eigentlich nicht so vorgesehen. Normalerweise blockt oder erlaubt man bei OpnSense nur mit "in" Rules. Oder wie meinst Du das?

2. Wenn Du nur 3 VLANs hast, dann helfen Dir die "Bereiche" oder "sortingnetze" doch nichts, weil innerhalb eines VLANs jeder mit jedem frei kommunizieren kann? D.h. "sonst wenn sich Rule in einem Netz befindet" ist doch irrelevant? Es läuft darauf hinaus, dass Du keine Regeln innerhalb eines VLANs brauchst, bzw. diese unwirksam wären.

Ich mache das eigentlich so, dass ich zunächst jedes VLAN mal gegen RFC1918 abschotte (außer den höher privilegierten VLANs, also z.B: Management) - die dürfen alles. Abgesehen davon dürfen die aber auch jedes Ziel, also ins Internet. An sich ist es ziemlich egal, ob wir über ein IoT-VLAN sprechen, ein normales Client-VLAN oder ein Gast-VLAN - ohne Internet geht meist sowieso nichts.

Danach muss ich mir nur noch überlegen, welche Dienste ich habe, die trotzdem geöffnet werden müssen, dass mache ich mit PASS-Regeln davor. Sofern es zentrale Dienste wie DNS, NTP o.ä. sind, richten die sich sowieso an "This Firewall" und können für alle Netze oder Gruppen (ich habe eine für die "weniger privilegierten VLANs") in den Floating Rules freigegeben werden.

Sind es spezielle Services, wie z.B: Zugriff auf einen Fileserver im LAN, definiere ich einen Alias für die erlaubten Clients und einen für die zum Service gehörigen Ports und erlaube es per Floating PASS-Regel. In den Interface-Regeln sind eigentlich nur die Block-RFC1918 und die Pass-Any-Regeln, abgesehen natürlich von WAN-Regeln.

Zur Organisation kann man Categories nutzen, danach lässt sich die Anzeige auch filtern, wenn das zu viele Regeln werden.

Neuerdings gibt es auch die "Automation"-Sektion, das habe ich aber noch nicht genutzt.


Mehr VLANs habe ich nur in einem Kontext: Wenn ich tatsächlich Services auf einem Hosting-Server (innerhalb Proxmox) trenne, weil diese aus dem Internet erreichbar sind und isoliert sein sollen. Dann nutze ich auf Proxmox eine "VLAN-aware" Bridge, auf dem für jeden Server ein VLAN aufliegt. Aber selbst dort brauche ich nur Gruppenregeln, weil diese Server untereinander keine Berziehung haben und von der Firewall aus (wo der Reverse Proxy läuft) ist sowieso jeder erreichbar - die Anzahl der Regeln dort ist also auch überschaubar. Es ist allerdings pro Server ein VLAN in OpnSense - Proxmox "kennt" diese aber natürlich nicht.

[kosta]

"1. Was heißt "OPNsense blockiert ausgehend, so Bedarf das eigentlich ein Umdenken."? Das ist eigentlich nicht so vorgesehen. Normalerweise blockt oder erlaubt man bei OpnSense nur mit "in" Rules. Oder wie meinst Du das?"

Eh so wie du geschrieben hast, meine Aussage war nur etwas schlampig. IN wie "interface ingress". Barracuda und andere Firewalls die ich kenne, haben das nicht so. Dort ist einfach nur Verkehr a->b, zeigt dir den Interface, aber basiert den Block nicht auf intf ingress.

"2. Wenn Du nur 3 VLANs hast, dann helfen Dir die "Bereiche" oder "sortingnetze" doch nichts, weil innerhalb eines VLANs jeder mit jedem frei kommunizieren kann? D.h. "sonst wenn sich Rule in einem Netz befindet" ist doch irrelevant?"

Ich habe insg. 6 VLANs - MGMT, LAN, PROD, DMZ_INT, DMZ_EXT, GUEST. Nicht ganz irrelevant, glaub ich. Hier sollten nur gewisse Server drin sein, die entweder von dem internen LAN/PROD separiert werden, bzw. von außen erreichbar sind. Und auf diese Server kommen sowohl Geräte aus LAN und PROD hin, bestimmte Services nur versteht sich. Wenn Floating, dann wohl ganze Netze, wenn einzelne Devices, dann entsprechende Interfaces. Sehe ich da was falsch?

"Ich mache das eigentlich so, dass ich zunächst jedes VLAN mal gegen RFC1918 abschotte"

Ich versuche mal zu summieren:
- in jeden VLAN hast ein Deny RFC1918, aber allow any-port non-RFC1918 (oder hab ich das verstanden, weil...)
- du machst einen pass rule vor dem obigen für spezielle services (also filterst du doch ins internet nach port?)
- MGMT hat ein MGMT-any-any rule
- Floating Rules für alles andere intern, so ziemlich das gleiche Prinzip was ich oben abgebildet habe

Ist das in etwa korrekt?

Um genau zu fragen:
"Abgesehen davon dürfen die aber auch jedes Ziel, also ins Internet."
Heißt du filterst nicht per Port ausgehend ins Internet? Ich würde persönlich da eher setzen auf HTTP/S OK für alle, aber dann doch eines oder ein paar Rules die ins Internet nur bestimmte Ports freigeben. Da ich bisher aber oft da reingefallen bin, dass irgendein Spiel nicht geht oder so, wäre vlt sinnvoll im PROD genau zu filtern, da dort doch alles kontrolliert abgeht, und im LAN sowieso alles Richtung Internet erlauben.

Außerdem wird bestimmt noch IoT VLAN kommen, ich weiß nicht wo mein Kopf war, wo ich IoT Devices ins gleiche VLAN wie meinen internen NGINX und DNS platziert hab... omg. :D

[meyergru]

Hier sind meine typischen Interface-Regeln (wie gesagt, abgesehen vom Management-VLAN):

You cannot view this attachment.

Wie Du siehst, nutze ich anstelle von RFC1918 "LOCAL_VLANS net", wobei das die Gruppe aller lokalen Interfaces ist.

So sieht es bei den Floating Rules aus:

You cannot view this attachment.

(Dabei kommen oben drüber übrigens noch Block-Regeln für Emerging Threats, Firehol usw., aber nur für das WAN, weil die Floating-Regeln vor NAT-Regeln mit implizitem "PASS" gezogen werden und sonst Port-Forwards weit offen stünden.)

An sich stehen da aber wie gesagt zunächst Dinge, die "jeder braucht", wie DNS, dann die einzelnen Dienste. Was man in der Übersicht nicht sieht, sind die erlaubten Interfaces, meist steht es im Kommentar. RESTRICTED sind die niedriger privilegierten VLANs.

Und nein, ausgehend filtere ich nichts. In den weniger privilegierten Netzen ohnehin nicht - soll ich mit jemand, der mein Gast-Netz diskutieren, warum irgendwas nicht funktioniert? Oder bei IoT: Der Punkt ist doch, dass ich dort sowieso nicht kontrollieren kann, was die Cloud-Devices tun (nimm an, sie nutzen die "Phone-Home"-Verbindung auf dem "legalen Port 443", um rückwärts einen Proxy in das lokale Netz aufzubauen). Das ist ja gerade der Grund, warum diese VLANs isoliert sind. Auf keinen Fall will ich da jeder Anwendung hinterher turnen und dann nur das öffnen, was die jeweils braucht.

Im Grunde gilt das selbe im LAN: Aufgrund der Tatsache, dass ich den Verkehr im Tunnel nicht kontrollieren kann, ohne ihn aufzubrechen, könnte Malware potentiell sowieso alles unbeobachtet tun. Ich könnte höchstens verhindern, dass bestimmte Command&Control-Server kontaktiert werden.

Adblocking mache ich anders und Kinder oder Angestellte, die ich reglementieren will, habe ich nicht.

All das kann man natürlich on top noch tun, bei mir sind es nur die zusätzlichen Inbound-Regeln, wie gesagt.