9
Firewallregeln eingehend oder besser ausgehend?
Hallo zusammen,
ich habe ein Frage zum grundsätzlichen Design von Firewallregeln. Bei mir betrifft das zum einen Debian nftables und OPNSense, aber das ist nicht so relevant.
Wenn man mehrere LAN-Schnittstellen und eine WAN-Schnittstelle hat, und Verkehr nach externen verbieten will (z.B. sagen wir einen speziellen externen Host) habe ich 2 Möglichkeiten:
Ich kann eingehende Pakete an allen LAN Schnittstellen blockieren. (Pseudocode)
Oder ich blockiere ausgehenden Verkehr am WAN Interface:
Welcehn Ansatz sollte man wählen?
Was bevorzugt Ihr? Gibt es da sowas wie best-practice?
Grüße
lcer
ich habe ein Frage zum grundsätzlichen Design von Firewallregeln. Bei mir betrifft das zum einen Debian nftables und OPNSense, aber das ist nicht so relevant.
Wenn man mehrere LAN-Schnittstellen und eine WAN-Schnittstelle hat, und Verkehr nach externen verbieten will (z.B. sagen wir einen speziellen externen Host) habe ich 2 Möglichkeiten:
Ich kann eingehende Pakete an allen LAN Schnittstellen blockieren. (Pseudocode)
block in on LAN1 from any to extHost
block in on LAN2 from any to extHost
block in on LAN3 from any to extHostOder ich blockiere ausgehenden Verkehr am WAN Interface:
block out on WAN from any to extHostWelcehn Ansatz sollte man wählen?
- Variante 1 braucht mehr Regeln -> langsamer?
- Variante 2 ist robuster, falls sich mal am Schnittstellensetup was ändert
- Variante 1 blockt die Pakete zeitiger -> schneller?
- Variante 1 ist übersichtlicher, wenn man am eingehenden Interface schaut
- Variante 2 ist übersichtlicher, wenn man am ausgehenden Interface schaut
Was bevorzugt Ihr? Gibt es da sowas wie best-practice?
Grüße
lcer
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: 653448
Url: https://administrator.de/contentid/653448
Printed on: April 19, 2024 at 19:04 o'clock
9 Comments
Latest comment
Hi,
für OPNSense (und pfSense) wird am LAN Interface ausgehend die Regel erstellt.
CH
für OPNSense (und pfSense) wird am LAN Interface ausgehend die Regel erstellt.
CH
Hallo.
Schließe mich @ChriBo an.
Wir setzen SonicWalls ein und dort haben auch per se Incoming on WAN blockiert (bzw. die Standard Block All Regel der Firewall nicht angepasst) und die ausgehenden Regeln an den entsprechenden Schnittstellen konfiguriert.
Einen Performance Verlust durch ein größeres Regelwerk konnten wir bis dato noch nicht feststellen.
Gruß
Marc
Schließe mich @ChriBo an.
Wir setzen SonicWalls ein und dort haben auch per se Incoming on WAN blockiert (bzw. die Standard Block All Regel der Firewall nicht angepasst) und die ausgehenden Regeln an den entsprechenden Schnittstellen konfiguriert.
Einen Performance Verlust durch ein größeres Regelwerk konnten wir bis dato noch nicht feststellen.
Gruß
Marc
Zitat von @ChriBo:
Hi,
für OPNSense (und pfSense) wird am LAN Interface ausgehend die Regel erstellt.
CH
Hi,
für OPNSense (und pfSense) wird am LAN Interface ausgehend die Regel erstellt.
CH
Moin,
Bei einer PfSense definitiv eingehend und statefull.
Was anderes macht keinen Sinn und würde bei einem block z.b. mehr Ressourcen verbrauchen. (Den Security Aspekt mal außen vor gelassen)
Du definierst ja nicht auf dem DMZ interface ob das LAN Interface Ressourcen der DMZ nutzen darf. Das passiert schon auf dem LAN Interface.
WAN seitig wird auch eingehend geblockt.
Gruß
Spirit
Bei einer PfSense definitiv eingehend und statefull.
So habe ich das auch verstanden. Über das genannte Interface in die Firewall eingehend.
Gruß
Looser
Hallo,
also: Grundregel - wenn immer möglich - eingehend blocken?
Grüße
lcer
also: Grundregel - wenn immer möglich - eingehend blocken?
Grüße
lcer
Ja, immer eingehend blockend. Ist ja auch logisch, denn warum sollte man ungewollten Traffic überhaupt erst auf die Firewall lassen der dann unnötig Processing Power verbraucht und das System belastet und die Sicherheit gefährdet. Kollege @Spirit-of-Eli hat es oben schon zu recht angesprochen das das wenig sinnvoll ist.
Solcher Traffic sollte aus diesen Gründen immer gleich aussen vor bleiben. Deshalb gilt bei allen Geräten immer inbound filtern. Outbound nur wenn man unbedingt muss und es gar nicht anders geht. Solche Fälle sind aber extrem selten. Zudem können viele Geräte outbound deshalb oft prinzipbedingt nicht in Hardware filtern sondern müssen das in Software erledigen was dann zusätzlich unnötig Performance kostet.
Solcher Traffic sollte aus diesen Gründen immer gleich aussen vor bleiben. Deshalb gilt bei allen Geräten immer inbound filtern. Outbound nur wenn man unbedingt muss und es gar nicht anders geht. Solche Fälle sind aber extrem selten. Zudem können viele Geräte outbound deshalb oft prinzipbedingt nicht in Hardware filtern sondern müssen das in Software erledigen was dann zusätzlich unnötig Performance kostet.
mh, andererseits: Firewallkonfigurationsfehler passieren, wenn man den überblick über die ganzen Regeln verliert, daher würde ich nicht nach performance (PS: Die kann man sowieso nicht "eyeballen", muss man messen, am code erkennt man nicht immer performanceprobleme bzw. schätzt es oft falsch ein).
Daher: Mach das, was deinem Denken entspricht und wo du am besten die Übersicht behälst.
Kompromiss: Variante 1, aber im code dann mit einer schleife über die drei lan interfaces --> übersichtlicher und wartungsärmerer code
Daher: Mach das, was deinem Denken entspricht und wo du am besten die Übersicht behälst.
Kompromiss: Variante 1, aber im code dann mit einer schleife über die drei lan interfaces --> übersichtlicher und wartungsärmerer code
Zitat von @NetzwerkDude:
mh, andererseits: Firewallkonfigurationsfehler passieren, wenn man den überblick über die ganzen Regeln verliert, daher würde ich nicht nach performance (PS: Die kann man sowieso nicht "eyeballen", muss man messen, am code erkennt man nicht immer performanceprobleme bzw. schätzt es oft falsch ein).
Daher: Mach das, was deinem Denken entspricht und wo du am besten die Übersicht behälst.
Kompromiss: Variante 1, aber im code dann mit einer schleife über die drei lan interfaces --> übersichtlicher und wartungsärmerer code
mh, andererseits: Firewallkonfigurationsfehler passieren, wenn man den überblick über die ganzen Regeln verliert, daher würde ich nicht nach performance (PS: Die kann man sowieso nicht "eyeballen", muss man messen, am code erkennt man nicht immer performanceprobleme bzw. schätzt es oft falsch ein).
Daher: Mach das, was deinem Denken entspricht und wo du am besten die Übersicht behälst.
Kompromiss: Variante 1, aber im code dann mit einer schleife über die drei lan interfaces --> übersichtlicher und wartungsärmerer code
Was aber nicht zwangsweise funktioniert..
...und auch der völlig falsche Ansatz ist, weil man den Faktor Mensch als Grundprinzip nimmt. Fatal bei einer Firewall und ein NoGo !
