[gelöst] Firewall -> (Interface) Groups

[kosta]

Hallo,

kann mir jemand etwa erklären wie die Firewall-Gruppen, in welchen Situationen, verwendet werden?
Ich versuche allgemeine Rules wie ausgehende 80/443 oder DNS aus einzelnen Interfaces zu entfernen, und dort eigentlich nur spezifische Rules haben. Die obigen Ports sind ja auf nahezu allen Interfaces vorhanden.
Macht das Sinn?

Und wenn man dafür Gruppe verwenden würde, wie benennt ihr die Gruppen in etwa? Ich habe gesehen dass für jede Gruppe ein Untermenü entsteht, ich kann mir nur vorstellen dass ich dann einige Gruppen dort entstehen, wie zB. GRP_Web_Surfing, GRP_DNS_Out usw. Einfach alle Interfaces in eine Gruppe zu bündeln wäre mir etwas zu viel, da ich damit nicht genug Freiheit habe.

Aber vielleicht das überhaupt eine falsche Anwendung. Suche hier einfach nach den Anwendungsszenarien.

Danke

[JeGr]

Ich muss ja schon sagen, in der Zahl wie du hier die unterschiedlichsten Themen ins Forum postest, finde ich die Aussage "ich brauch keinen Support" schon lustig. Aber warum sollte man Firewall KnowHow auch bezahlen

Interface Gruppen kann man vielfach anwenden, da braucht es gar keine große Phantasie. Sobald man einmal ernsthafter über Security Konzepte und Netzwerk-Architektur nachdenkt und anfängt, sein Firmen-Netzwerk sinnvoll zu segmentieren, ergeben sich automatisch Anwendungsfälle. Und seien es nur so einfache wie Nutzung für Infrastruktur-Regeln, die dann auf alle sie brauchenden VLAN Interfaces gemappt werden.

Gibt natürlich auch Fußangeln bei Blocks/Rejects oder im Cluster aber das ist dann die Abwägung, was man wo an welcher Stelle haben möchte.

Cheers

[lfirewall1243]

Ich muss ja schon sagen, in der Zahl wie du hier die unterschiedlichsten Themen ins Forum postest, finde ich die Aussage "ich brauch keinen Support" schon lustig. Aber warum sollte man Firewall KnowHow auch bezahlen

 

Cheers

Genau das habe ich mir auch gedacht

[thogru]

Moin, moin,

So wie ich die Interface-Gruppen verstehe dienen sie zwei Zielen:

• Durch die Baumstruktur der Interface-Gruppen werden viele Interface (meistens in verschiedenen VLANs) zusammengefasst
• Ich überlege auf unterster Ebene jedem physischem Interface ein eigene Gruppe zu spendieren, damit ich bei Bedarf das Interface tauschen kann, ohne die Regeln anpassen zu müssen (siehe).

Gruß
Thomas

[kosta]

Und ich muss dann ja auch schon sagen, dass ich mich hier manchmal richtig seltsam behandelt und angegriffen fühle.
Dein Post, Jens, hat mich gerade ehrlich gesagt extrem irritiert:

Ich muss ja schon sagen, in der Zahl wie du hier die unterschiedlichsten Themen ins Forum postest, finde ich die Aussage "ich brauch keinen Support" schon lustig. Aber warum sollte man Firewall KnowHow auch bezahlen

Also versuchen wir es nochmal sachlich und im Klartext:
Wo habe ich gesagt "ich brauch keinen Support", wortwörtlich? Meines Wissens nach nie.
Falls ich genau sowas gesagt habe, dann war es durchaus falsch. Ganz im Gegenteil.
Ich habe vor paar Wochen das Budget für paar Umstellungen vorgestellt (wir schaffen neue Internet-Leitung, Firewall und Telefonie an), und dazu auch einen 10Std-Support-Block für die Umstellung der Firewall eingeplant/budgetiert.
Was ich aber ziemlich sicher gesagt habe, ist dass ich einen laufenden Wartungs-Vertrag (=monatliche Kosten) nicht durchbringen kann (und meiner Meinung nach, für unsere Bedürfnisse, nicht brauche). Ist nicht budgetiert, wird nicht genehmigt und ist nicht möglich.

Dass mein KnowHow nicht auf der Ebene von gewissen Personen hier ist (du inkludiert natürlich auch), ist mir schon klar. Ich verstehe aber nicht, warum das eine Erwartungshaltung ist?

Weißt eigentlich, ich bin auf mich selbst eigentlich sehr stolz was ich alles seit 2013 geschafft habe zu lernen, abgesehen davon dass ich damals nicht mal wusste was ein Server oder Netzwerk ist. Geschweige Linux, Open Source, oder ähnliches. Das war der Beginn meiner IT-Karriere.
Teure Kurskosten kann ich mir nicht leisten, die Quellen (Bücher, Videos, CBT, Web...) die ich kannte oder kenne habe ich genutzt und eigentlich nur mit sehr viel Selbstmotivation und Eigeninteresse vorangekommen.
Die Firma bezahlt es auch limitiert, sicher keine Tausenden an Euros um Zertifizierungen zu bekommen.
Ist halt so. Aber sie zahlen mir zumindest aktuell die CBTs die ich selbst nutzen kann um voran zu kommen.
Aber das tolle dahinter: ich hab ein großes Interesse und Affinität für die IT und freue mich ständig neue Sachen gelernt zu haben.
Wäre schön hätte ich ein Umfeld in dem ich von erfahrenen IT'lern lernen könnte, habe ich aber leider nicht.
Nur so viel mal zum Background.

Ihr könntet (müsst aber nicht) das auch positiv sehen, dass ich mich für diese Sachen interessiere und strebe einer Besserung an. Letztendlich, will man dazu nichts beitragen, muss man ja nicht antworten.

Letztendlich, dein zweites Teil des Postings ist wiederum für mich sehr nützlich und etwas was ich in meiner Planung gut einbinden kann.
Das aber was du geschrieben hast, ist eben genau das, was ich schon als Idee in meinem ersten Post geschrieben habe. Ich habe lediglich um Best Practices gefragt, und sehe dabei nichts falsches, definitiv keinen Ansatz für ein solches Posting (Teil1).

Gibt natürlich auch Fußangeln bei Blocks/Rejects oder im Cluster

Ich glaube mein Deutsch reicht nicht das hier genau zu verstehen. Kannst du erklären bitte?

[kosta]

Moin, moin,

So wie ich die Interface-Gruppen verstehe dienen sie zwei Zielen:

• Durch die Baumstruktur der Interface-Gruppen werden viele Interface (meistens in verschiedenen VLANs) zusammengefasst
• Ich überlege auf unterster Ebene jedem physischem Interface ein eigene Gruppe zu spendieren, damit ich bei Bedarf das Interface tauschen kann, ohne die Regeln anpassen zu müssen (siehe).

Gruß
Thomas

Servus!
Jep, VLANs habe ich (zu Hause mehr Spielerei als was anderes, in der Firma eine logische und überlegte Trennung zwischen Bereichen), und genau dafür erstmal eingesetzt. Hab mit simplen Aufgaben angefangen, Web und DNS, aber bin dann irgendwie hängen geblieben, da ich so schnell eine elendlange Liste im Firewall-Menü bekomme... deswegen wollte ich mal eure Überlegungen wie die Interfaces gruppiert werden, nach welchen Regeln... blöd ist es für mich die Gruppe Web_Surfing zu nennen... wahrscheinlich geht es mir rein um das Benennen der Gruppen. Logisch, verständlich, und wofür genutzt, verstehe ich sowieso! Und blöd bin ich nicht, um mir auszudenken wofür ich die verwende (sorry, ist noch etwas "Venting" von vorher dabei...)

Und wie du auch schon in deinem Post erklärt hast... zu Hause habe ich schon etliche Aliase, weil ich VPN mit Firma hab. Wenn ich dann die Migration von Sophos auf OPNsense mache, wird das viel viel länger. Und genau da versuche ich, eine neue Planung mit möglichst viel Ordnung zu machen (und ich rede hier nicht von der technischen Aufstellung, sondern Ordnung in der Firewall).

Aktuell ist es so, dass ich viele Rules kopiert (geclont) habe. Und viele sind bei vielen Interfaces gleich. Aber nicht bei allen. zB. LAN hat NNTP out, aber IoT VLAN nicht.

[JeGr]

Ich glaube mein Deutsch reicht nicht das hier genau zu verstehen. Kannst du erklären bitte?

Sicher. Gruppen stehen in der Reihenfolge der Abarbeitung woanders als Interfaces. Oder Floatings. Floats, Gruppen + Sondergruppen, Interfaces. Ein Block in Gruppen wird also ausgeführt bevor es ins Interface geht. Darum gefährlich wenn man die Reihenfolge nicht im Auge behält. Genauso multiple Gruppen.
Oder bei einem Cluster. Da Gruppen keine Synchronizität haben, werden Änderungen an Interfacezuordnungen dort gerne übersehen.

Zu dem 2. Punkt was Thogru schrieb, wäre ich vorsichtig. Bei Gruppen gehen verschiedene Funktionen verloren. Vor allem wäre ich vorsichtig, WAN Interfaces als Gruppe zusammenzufassen, da sonst ggf. das reply-to für Antwort über das korrekte Gateway verloren geht. VLANs nochmal in Gruppen zu fassen (wo nur sie alleine drin sind) macht keinen Sinn, dafür ist ja genau die Abstraktionsschicht da, die aus bspw. igb0 ein opt3 macht. Eben damit man das Interface tauschen kann.


Zu dem anderen Post enthalte ich mich. Halte nichts von öffentlichem Drama.

Cheers

[kosta]

Verstehe, besten Dank.
Wenn schon, dann hätte ich vor meine LAN+VLAN Intf zusammenzufassen, um die Rules die auf alle gehen auf einem Ort zu halten und die Listen in den Intf selbst kürzer zu halten.
Das schaffe ich zum Teil mit den Aliasen.

Womit kann ich bei Gruppen oder Floating die Destination ersetzen? zB. bei DNS habe ich nur erlauben wenn es auf LAN Intf -> LAN net geht. In Gruppen oder Floats habe ich diese Möglichkeit nicht. Ersetzt "This Firewall" Alias die einzelnen Interface-IP-Adressen und wäre im Falle meiner DNS-Rules einsetzbar? (ich weiß dass "This Firewall" auch WAN-IP beinhaltet, daher die Frage)

Zu dem anderen Post enthalte ich mich. Halte nichts von öffentlichem Drama.

Vielen Dank.

[JeGr]

> Womit kann ich bei Gruppen oder Floating die Destination ersetzen? zB. bei DNS habe ich nur erlauben wenn es auf LAN Intf -> LAN net geht. In Gruppen oder Floats habe ich diese Möglichkeit nicht.

Macht für mich gerade überhaupt keinen Sinn. Warum sollte ich "von LAN Int auf LAN net" DNS freigeben? Kommt nie vor.

> In Gruppen oder Floats habe ich diese Möglichkeit nicht.

Richtig, logischerweise, weil es keine definierten Quellen gibt.

> Ersetzt "This Firewall" Alias die einzelnen Interface-IP-Adressen und wäre im Falle meiner DNS-Rules einsetzbar? (ich weiß dass "This Firewall" auch WAN-IP beinhaltet, daher die Frage)

This Firewall enthält immer alle Adressen der Firewall und das ist oft nicht gewünscht. Zumal damit auch Aliase etc. abgedeckt sind.

[kosta]

Macht für mich gerade überhaupt keinen Sinn. Warum sollte ich "von LAN Int auf LAN net" DNS freigeben? Kommt nie vor.

Vielleicht Missverständnis. Wenn ein Client eine DNS Anfrage an die Firewall machen will, muss ich Port 53 am Firewall-Interface erlauben. Dafür habe ich aber die Destination auf LAN net gesetzt, um sicher zu gehen, dass die Anfragen nicht an externe DNS gehen können. Außerdem ist auch ein NAT Rule gesetzt, der sagt alle DNS Anfragen die nicht an die Firewall (!RFC1918) gehen, auf 127.0.0.1 umgeleitet werden.
Das ist alles bei mir zu Hause, daher nicht kritisch, aber wenn die Firewall in der Firma konfiguriert wird, werde ich jede Funktionalität die ich einbaue, auch genau überprüfen, ob sie funkt so wie angedacht. Dafür habe ich den ganzen Sommer Zeit...

This Firewall enthält immer alle Adressen der Firewall und das ist oft nicht gewünscht. Zumal damit auch Aliase etc. abgedeckt sind.

OK, ich glaube ich bin mittlerweile davon überzeugt dass ich weder Floating noch Gruppen wirklich brauchen werde, vielleicht nur für einzelne Rules. Da muss man sich eigentlich echt merken was man in Floating drinnen hat, und nicht gleich neue Rules in den Interfaces erstellen.

[chemlud]

Ich nutze floating v.a. für BLOCK rules....

[kosta]

Ahh genau, guter Tipp! Danke!

[JeGr]

> Vielleicht Missverständnis. Wenn ein Client eine DNS Anfrage an die Firewall machen will, muss ich Port 53 am Firewall-Interface erlauben. Dafür habe ich aber die Destination auf LAN net gesetzt, um sicher zu gehen, dass die Anfragen nicht an externe DNS gehen können. Außerdem ist auch ein NAT Rule gesetzt, der sagt alle DNS Anfragen die nicht an die Firewall (!RFC1918) gehen, auf 127.0.0.1 umgeleitet werden.

Das macht aber keinen Sinn. LAN net ist doch völlig sinnbefreit. Die Anfrage geht an den DNS Server der per DHCP gepusht wird. Normalerweise also die entsprechende IP der Firewall auf dem Interface. Also LAN Addr und nicht LAN net. Warum sollte ich unnötig das ganze Netz aufmachen. Wenn dann geht die Regel von SOURCE LAN net auf Destination LAN address Port 53. Sonst nix. Und die Redirection Rule greift dann für udp/53 Ziele !(LAN address) damit die umgeschrieben werden auf LAN. Oder localhost, wie man das handhaben will ist egal.

Aber genau sowas kann man dann eben "optimieren" mit nem Alias von allen VLAN Netzen als Source, Destination ist "this firewall" (weil es dann um gezielten Zugriff von udp/53 geht) als Destination und die Regel in ner entsprechenden Gruppe. Genau das war u.a. mit Infrastruktur Regeln gemeint. DNS, NTP, etc. Was aus jedem (V)LAN gehen soll. Was eigene Infrastruktur Grunddienste sind.

> Ich nutze floating v.a. für BLOCK rules....

Kann man ruhig machen, ich halte es für gefährlich weil es viele Leute eben aus den Augen verlieren und sich dann krumm suchen. Die Praxis hat gezeigt, dass die Admins Blocks eher sehen, wenn sie auf dem Interface selbst sind als in Floats. Zudem kann man dann keine Ausnahmen mehr auf dem Interface definieren, weil die Floating davor sitzt und alles wegfrisst. Genau daher meinte ich oben, dass es Fußangeln gibt bei Gruppen wie bei Floating wenn man mit Blocks/Rejects darin rumspielt. Dann bekommt man ruck zuck Komplexität rein, die man vielleicht vermeiden möchte, nur um ein zwei Regeln extra zu sparen.

[chemlud]

...
> Ich nutze floating v.a. für BLOCK rules....

Kann man ruhig machen, ich halte es für gefährlich weil es viele Leute eben aus den Augen verlieren und sich dann krumm suchen. Die Praxis hat gezeigt, dass die Admins Blocks eher sehen, wenn sie auf dem Interface selbst sind als in Floats. Zudem kann man dann keine Ausnahmen mehr auf dem Interface definieren, weil die Floating davor sitzt und alles wegfrisst. Genau daher meinte ich oben, dass es Fußangeln gibt bei Gruppen wie bei Floating wenn man mit Blocks/Rejects darin rumspielt. Dann bekommt man ruck zuck Komplexität rein, die man vielleicht vermeiden möchte, nur um ein zwei Regeln extra zu sparen.

Aber das ist doch relativ einfach: Die Dinge die ich ÜBERHAUPt nicht will, sind floating, alles Spezifische ist auf den einzelnen Interfaces. Kann man sich doch merken. Selbst in meinem Alter funktioniert das ganz gut...

[kosta]

Die Anfrage geht an den DNS Server der per DHCP gepusht wird.

Korrekt. Bis man es in der NIC nicht händisch ändert.

Also LAN Addr und nicht LAN net.

Korrekt, die Anfragen gehen by default an LAN Addr. Und jetzt sehe ich dass sich im Posting ein Fehler eingeschlichen hat... mein Rule heißt:
IPv4 TCP/UDP   LAN net   *   LAN address   53 (DNS)   *   *   DNS

Also tut mir für die Verwirrung echt leid.

Aber genau sowas kann man dann eben "optimieren" mit nem Alias von allen VLAN Netzen als Source, Destination ist "this firewall" (weil es dann um gezielten Zugriff von udp/53 geht) als Destination und die Regel in ner entsprechenden Gruppe. Genau das war u.a. mit Infrastruktur Regeln gemeint. DNS, NTP, etc. Was aus jedem (V)LAN gehen soll. Was eigene Infrastruktur Grunddienste sind.

Genau! Da sind wir ja doch bei der gleichen Sache doch! Hab das noch gestern gemacht:
FIREWALL: RULES: GRP_GEN_PROTO
       Protocol   Source   Port   Destination   Port   Gateway   Schedule   Description    
        IPv4 TCP/UDP   GRP_Gen_Proto net   *   This Firewall   53 (DNS)   *   *   DNS       
        IPv4 TCP   GRP_Gen_Proto net   *   *   80 (HTTP)   *   *   HTTP       
        IPv4 TCP/UDP   GRP_Gen_Proto net   *   *   443 (HTTPS)   *   *   HTTPS       
        IPv4 TCP/UDP   GRP_Gen_Proto net   *   *   8080   *   *   HTTP Alternate       
        IPv4 UDP   GRP_Gen_Proto net   *   *   123 (NTP)   *   *   NTP       
        IPv4 ICMP   GRP_Gen_Proto net   *   *   *   *   *   Allow ICMP (Echo Req)       

GRP_Gen_Proto ist eben LAN+VLANs.

Aber das ist doch relativ einfach: Die Dinge die ich ÜBERHAUPt nicht will, sind floating, alles Spezifische ist auf den einzelnen Interfaces. Kann man sich doch merken. Selbst in meinem Alter funktioniert das ganz gut...

Mir fällt ehrlich gesagt gar nix ein, was ich blocken müsste. Hab mal Internet am Hyper-V geblockt, aber das war's. Sonst ist eh alles gesperrt, da man nur das erlaubt, was auch nötig ist.
Hast vielleicht ein Beispiel für mich?