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)

block in on LAN1 from any to extHost
block in on LAN2 from any to extHost
block in on LAN3 from any to extHost

Oder ich blockiere ausgehenden Verkehr am WAN Interface:

block out on WAN from any to extHost

Welcehn 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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 653448

Url: https://administrator.de/forum/firewallregeln-eingehend-oder-besser-ausgehend-653448.html

Ausgedruckt am: 12.04.2025 um 09:04 Uhr

9 Kommentare

Neuester Kommentar

Hi,
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

Zitat von @ChriBo:

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

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.

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

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

Was aber nicht zwangsweise funktioniert..