Firewall Topologien: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(41 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=FIREWALL TOPOLOGIEN=
+
=Einfacher Paketfilter=
*[[Einfacher Paketfilter]]
+
*Einfacher Paketfilter: das interne Netz wird mit einem Router an ein öffentliches Netz angebunden. Der Router arbeitet aber selektiv.
*[[Dual Homed Host]]
+
*Das bedeutet, dass nur bestimmte Arten von Paketen das Passieren erlaubt wird, anderen wird es nicht gewährt.
*[[Statefull Packet Inspection]]
+
*Paketfilter arbeitet auf den untersten 4 Schichten der TCP/IP-Architektur.
 +
*Bis heute die Basis: nftables/iptables und die unterste Schicht jeder modernen Firewall (NGFW) arbeiten nach demselben Prinzip.
 +
==Vorteile der Paketfilterung==
 +
*kann ganzes Netzwerk schützen
 +
*extrem effektiv
 +
*schnell, da über die Verbindungen nicht Buch geführt wird
  
*[[Architektur mit überwachten Hosts]]
+
==Nachteil==
 +
*Filterbeschreibungen sind nicht perfekt
 +
*Router wird belastet
 +
*Nicht alle Sicherheitsrichtlinien lassen sich durchsetzen
 +
*kein Zustand, keine Anwendungserkennung → siehe Stateful Packet Inspection und NGFW
 +
{{#drawio:paketfilter}}
  
 +
=Application- und Circuit-Level-Proxys (historisch: Dual Homed Host)=
 +
*Auf einem Dual Homed Host liefen früher sogenannte Proxys (Stellvertreter). Ein Proxy arbeitet auf allen 7 Schichten des ISO/OSI-Modells und kommt damit mit dem Anwendungsprotokoll in Berührung.
 +
*Es gibt 2 verschiedene Arten:
 +
**'''Application Level Proxys''' kennen das Anwendungsprotokoll genau (Beispiel: Squid, ein cache-only Nameserver) — vergleichbar mit einem Dolmetscher.
 +
**'''Circuit Level Proxys''' kennen das Anwendungsprotokoll nicht, sie „quatschen“ alles nur nach oder setzen es um (Beispiel: SOCKS, Delegated) — vergleichbar mit einem Übersetzungsprogramm.
 +
*Vorteile: gutes Protokollieren, Caching, anwendungsspezifische Filterung, Authentifikation auf Userebene, kein IP-Forwarding notwendig.
 +
*Nachteile: neuere Protokolle werden nicht unterstützt, verschiedene Proxyserver für verschiedene Dienste notwendig, Clients müssen ihr Verhalten ändern.
 +
*Der Dual Homed Host als eigenständige Architektur ist heute selten — die Idee lebt aber in jedem Forward-/Reverse-Proxy weiter, der heute meist in der DMZ oder als Teil einer NGFW läuft. Interaktive Szenarien (Forward Proxy, Reverse Proxy, SSL-Bump mit ICAP/ClamAV, Application vs. Circuit Level) siehe proxy.html.
 +
{{#drawio:dualhomedhost}}
  
==Architektur mit überwachtem Teilnetz(mit zwei Paketfiltern)==
+
=Stateful Packet Inspection=
 +
*Unter Stateful Packet Inspection (SPI; deutsch: zustandsorientierte Paketüberprüfung) versteht man eine dynamische Paketfiltertechnik.
 +
*Jedes Datenpaket wird einer bestimmten aktiven Session zugeordnet.
 +
*Die Datenpakete werden analysiert und der Verbindungsstatus wird in die Entscheidung einbezogen.
 +
*Die Datenpakete werden während der Übertragung auf der Vermittlungsschicht analysiert und in dynamischen Zustandstabellen gespeichert.
 +
*SPI ist heute keine eigenständige Technologie mehr, sondern Standardfunktion in praktisch jeder Firewall/NGFW — ohne SPI gilt eine Firewall heute nicht mehr als zeitgemäß.
 +
{{#drawio:StatefullPacketInspection}}
  
*[[Geteiltes und überwachtes Teilnetz mit Dual-Homed-Host]]
+
=Screened Subnet (DMZ)=
 +
*Exponierte Dienste stehen in einem eigenen Grenznetz (DMZ) zwischen äußerem und innerem Paketfilter.
 +
*Das Grenznetz ist ein eigenes Netzsegment — äußerer und innerer Filter sind direkt darüber verbunden. Hosts wie Webserver oder Proxy hängen nur an diesem Segment, sie sind nicht selbst der Übergang zwischen den beiden Filtern.
 +
*Äußerer Filter lässt vom Internet nur Traffic zu den Diensten in der DMZ zu (z.B. Webserver), nicht weiter ins interne Netz.
 +
*Innerer Filter lässt nur begrenzten, erwarteten Traffic von der DMZ ins interne Netz.
 +
*Kompromittierter Dienst in der DMZ hat keinen direkten Zugriff aufs interne Netz.
 +
*Die DMZ kann in beide Richtungen genutzt werden: eingehend über einen Webserver/Reverse-Proxy, ausgehend über einen Forward-Proxy für die internen Clients (statt direktem IP-Forwarding — die alte Dual-Homed-Host-Idee lebt hier weiter).
 +
*Skaliert auf mehrere Grenznetze, z.B. für ein zusätzliches Partnernetz (Vertriebspartner), das genauso angebunden wird.
 +
*Bis heute das Standardmuster für Mailserver, Webserver, VPN-Gateways — nur dass die zwei Filter heute meist Zonen einer einzigen NGFW sind statt zwei getrennter Geräte.
 +
;Getrennt
 +
{{#drawio:dmz_screened_subnet}}
 +
;Zusammengelegt
 +
{{#drawio:dmz_screened_zusammen}}
  
 +
=Von getrennten Paketfiltern zur Next-Generation Firewall (NGFW)=
 +
*Häufig legen kommerzielle Produkte den inneren und äußeren Paketfilter zusammen — das war schon vor Jahren die übliche Bauform, bevor NGFWs den Namen dafür bekamen.
 +
*Eine NGFW bündelt das, was früher mehrere Geräte/Schritte waren, in einer Plattform:
 +
**'''App-ID''': erkennt Anwendungen unabhängig vom Port, statt nur nach IP/Port zu filtern
 +
**'''TLS/SSL-Inspection''', weil praktisch aller Traffic heute verschlüsselt ist
 +
**'''IPS/Sandboxing''' gegen bekannte und unbekannte Bedrohungen
 +
**zunehmend '''KI-gestützte Anomalieerkennung'''
 +
*NGFW ist heute der De-facto-Standard in Unternehmen. Sie ersetzt nicht die Konzepte aus den vorherigen Abschnitten, sondern bündelt sie in einer Plattform.
 +
{{#drawio:ngfw}}
  
 +
=Zero Trust / ZTNA=
 +
*'''Zero Trust''' bedeutet: keine Instanz im Netzwerk wird automatisch als vertrauenswürdig behandelt, nur weil sie sich am „richtigen" Ort befindet (z.B. im internen Netz). Jede einzelne Verbindung muss sich ausweisen.
 +
*Der Bruch mit dem klassischen Perimeter-Denken: Es gibt kein pauschal vertrauenswürdiges „internes Netz“ mehr.
 +
*Jede Verbindung wird einzeln anhand von Identität, Gerätezustand und Kontext autorisiert — unabhängig davon, wo der Client sitzt.
 +
*Deny-by-default: ohne explizite Erlaubnis keine Verbindung.
 +
*Zugriff ist immer anwendungsspezifisch, nie netzwerkweit (z.B. Zugriff auf genau eine interne App, nicht auf das ganze Subnetz).
 +
*Löst zunehmend klassische VPN-Zugänge als Angriffsfläche ab — ein kompromittiertes VPN gibt sonst Zugriff aufs ganze Netz, ein kompromittierter ZTNA-Zugang nur auf die eine freigegebene Anwendung.
 +
*'''ZTNA (Zero Trust Network Access)''' ist die technische Umsetzung von Zero Trust: der Zugriffsweg, über den diese Prüfung pro Verbindung tatsächlich stattfindet.
 +
*ZTNA ist mittlerweile Standardbestandteil in Enterprise-NGFWs — es ersetzt Screened Subnet/DMZ nicht, ergänzt sie aber um eine Prüfung pro Zugriff statt pro Netzzone.
 +
{{#drawio:zerotrust}}
  
 
+
=Cloud-native Security / SASE=
 
+
*'''SASE (Secure Access Service Edge)''' beschreibt, wie die klassische Firewall-Hardware im eigenen Rechenzentrum durch einen Sicherheits-Stack in der Cloud ersetzt wird.
*[[Architektur mit zusammengelegtem inneren und äusseren Paketfilter]]
+
*Egal ob Remote-Nutzer oder Zweigstelle: der Traffic läuft immer zuerst über denselben Cloud-Sicherheitsstack, bevor er sein Ziel erreicht.
 
+
*SASE bündelt vier Bausteine in einem Dienst:
==Architektur mit zusammengelegtem inneren und äusseren Paketfilter und mehreren Grenznetzen==
+
**'''SWG (Secure Web Gateway)''': prüft und filtert ausgehenden Web-Traffic — der Cloud-Nachfolger des klassischen Forward-Proxys.
 
+
**'''CASB (Cloud Access Security Broker)''': überwacht die Nutzung von Cloud-Diensten wie Microsoft 365 oder Salesforce, z.B. um zu verhindern, dass Firmendaten in private Cloud-Speicher hochgeladen werden.
[[Datei:innenaußengrenznetze.png]]
+
**'''FWaaS (Firewall-as-a-Service)''': die klassische Firewall-Funktion (Paketfilter, SPI, NGFW-Features) als gemieteter Cloud-Dienst statt als eigene Hardware im Serverraum.
 
+
**'''ZTNA''': siehe vorheriger Abschnitt — die identitätsbasierte Zugriffskontrolle pro Verbindung.
==Architektur mit mehreren Grenznetzen==
+
*Ein Enforcement-Punkt für alle Standorte statt Hardware pro Standort — Policy folgt dem Nutzer, nicht dem Netzwerkstandort.
 
+
*Besonders relevant für Unternehmen mit vielen Standorten oder viel Remote-Arbeit.
 
+
{{#drawio:sase}}
[[Bild:grenznetzen1.png]]
 
 
 
 
 
Äussere Paketfilter lässt nur Traffic zu dem Bastion Host zu. Innerere Paketfilter lässt nur Traffic zu dem Bastion Host zu die Clients kommunizieren nur mit den Proxys auf dem Bastion Host Das Partnernetz (z.B.Vetriebspartner) wird genauso angebunden.
 
 
 
=Statefull Packet Inspection=
 
 
 
[[Datei:StatefullPacketInspection.png]]
 
 
 
==Architektur mit überwachten Hosts==
 
 
 
 
 
 
 
 
 
[[Bild:architektur1.png]]
 
 
 
Der Paketfilter lässt nur Traffic zu dem Bastion Host zu, die Clients kommnuzieren nur
 
mit den Proxys auf dem Bastion Host.
 
 
 
==Architektur mit überwachtem Teilnetz(mit zwei Paketfiltern)==
 
 
 
 
 
Äussere Paketfilter lässt nur Traffic zu dem Bastion Host zu. Innerere Paketfilter lässt nur Traffic zu dem Bastion Host zu die Clients kommunizieren nur mit den Proxys auf dem Bastion Host
 
 
 
 
 
[[Bild:architekturteilnetz1.png]]
 
 
 
==Geteiltes und überwachtes Teilnetz mit Dual-Homed-Host==
 
 
 
 
 
[[Bild:geteitelstdualhost1.png]]
 
 
 
 
 
 
 
Äussere Paketfilter lässt nur Traffic zu dem Dual-Home-Host zu. Innerere Paketfilter lässt nur Traffic zu dem Dual-Home-Host  zu die Clients kommunizieren nur mit den Proxys auf dem Bastion Host. Kein Forwarding auf dem Dual-Home-Host
 
 
 
==Architektur mit zusammengelegtem inneren und äusseren Paketfilter==
 
 
 
 
 
[[Bild:paketfilterinnenaußen1.png]]
 
 
 
 
 
Häufig haben kommerzielle Produkte diese Layout
 
 
 
==Architektur mit zusammengelegtem inneren und äusseren Paketfilter und mehreren Grenznetzen==
 
 
 
[[Datei:innenaußengrenznetze.png]]
 
 
 
==Architektur mit mehreren Grenznetzen==
 
 
 
 
 
[[Bild:grenznetzen1.png]]
 
 
 
 
 
Äussere Paketfilter lässt nur Traffic zu dem Bastion Host zu. Innerere Paketfilter lässt nur Traffic zu dem Bastion Host zu die Clients kommunizieren nur mit den Proxys auf dem Bastion Host Das Partnernetz (z.B.Vetriebspartner) wird genauso angebunden.
 

Aktuelle Version vom 28. Juli 2026, 04:45 Uhr

Einfacher Paketfilter

  • Einfacher Paketfilter: das interne Netz wird mit einem Router an ein öffentliches Netz angebunden. Der Router arbeitet aber selektiv.
  • Das bedeutet, dass nur bestimmte Arten von Paketen das Passieren erlaubt wird, anderen wird es nicht gewährt.
  • Paketfilter arbeitet auf den untersten 4 Schichten der TCP/IP-Architektur.
  • Bis heute die Basis: nftables/iptables und die unterste Schicht jeder modernen Firewall (NGFW) arbeiten nach demselben Prinzip.

Vorteile der Paketfilterung

  • kann ganzes Netzwerk schützen
  • extrem effektiv
  • schnell, da über die Verbindungen nicht Buch geführt wird

Nachteil

  • Filterbeschreibungen sind nicht perfekt
  • Router wird belastet
  • Nicht alle Sicherheitsrichtlinien lassen sich durchsetzen
  • kein Zustand, keine Anwendungserkennung → siehe Stateful Packet Inspection und NGFW

Application- und Circuit-Level-Proxys (historisch: Dual Homed Host)

  • Auf einem Dual Homed Host liefen früher sogenannte Proxys (Stellvertreter). Ein Proxy arbeitet auf allen 7 Schichten des ISO/OSI-Modells und kommt damit mit dem Anwendungsprotokoll in Berührung.
  • Es gibt 2 verschiedene Arten:
    • Application Level Proxys kennen das Anwendungsprotokoll genau (Beispiel: Squid, ein cache-only Nameserver) — vergleichbar mit einem Dolmetscher.
    • Circuit Level Proxys kennen das Anwendungsprotokoll nicht, sie „quatschen“ alles nur nach oder setzen es um (Beispiel: SOCKS, Delegated) — vergleichbar mit einem Übersetzungsprogramm.
  • Vorteile: gutes Protokollieren, Caching, anwendungsspezifische Filterung, Authentifikation auf Userebene, kein IP-Forwarding notwendig.
  • Nachteile: neuere Protokolle werden nicht unterstützt, verschiedene Proxyserver für verschiedene Dienste notwendig, Clients müssen ihr Verhalten ändern.
  • Der Dual Homed Host als eigenständige Architektur ist heute selten — die Idee lebt aber in jedem Forward-/Reverse-Proxy weiter, der heute meist in der DMZ oder als Teil einer NGFW läuft. Interaktive Szenarien (Forward Proxy, Reverse Proxy, SSL-Bump mit ICAP/ClamAV, Application vs. Circuit Level) siehe proxy.html.

Stateful Packet Inspection

  • Unter Stateful Packet Inspection (SPI; deutsch: zustandsorientierte Paketüberprüfung) versteht man eine dynamische Paketfiltertechnik.
  • Jedes Datenpaket wird einer bestimmten aktiven Session zugeordnet.
  • Die Datenpakete werden analysiert und der Verbindungsstatus wird in die Entscheidung einbezogen.
  • Die Datenpakete werden während der Übertragung auf der Vermittlungsschicht analysiert und in dynamischen Zustandstabellen gespeichert.
  • SPI ist heute keine eigenständige Technologie mehr, sondern Standardfunktion in praktisch jeder Firewall/NGFW — ohne SPI gilt eine Firewall heute nicht mehr als zeitgemäß.

Screened Subnet (DMZ)

  • Exponierte Dienste stehen in einem eigenen Grenznetz (DMZ) zwischen äußerem und innerem Paketfilter.
  • Das Grenznetz ist ein eigenes Netzsegment — äußerer und innerer Filter sind direkt darüber verbunden. Hosts wie Webserver oder Proxy hängen nur an diesem Segment, sie sind nicht selbst der Übergang zwischen den beiden Filtern.
  • Äußerer Filter lässt vom Internet nur Traffic zu den Diensten in der DMZ zu (z.B. Webserver), nicht weiter ins interne Netz.
  • Innerer Filter lässt nur begrenzten, erwarteten Traffic von der DMZ ins interne Netz.
  • Kompromittierter Dienst in der DMZ hat keinen direkten Zugriff aufs interne Netz.
  • Die DMZ kann in beide Richtungen genutzt werden: eingehend über einen Webserver/Reverse-Proxy, ausgehend über einen Forward-Proxy für die internen Clients (statt direktem IP-Forwarding — die alte Dual-Homed-Host-Idee lebt hier weiter).
  • Skaliert auf mehrere Grenznetze, z.B. für ein zusätzliches Partnernetz (Vertriebspartner), das genauso angebunden wird.
  • Bis heute das Standardmuster für Mailserver, Webserver, VPN-Gateways — nur dass die zwei Filter heute meist Zonen einer einzigen NGFW sind statt zwei getrennter Geräte.
Getrennt
Zusammengelegt

Von getrennten Paketfiltern zur Next-Generation Firewall (NGFW)

  • Häufig legen kommerzielle Produkte den inneren und äußeren Paketfilter zusammen — das war schon vor Jahren die übliche Bauform, bevor NGFWs den Namen dafür bekamen.
  • Eine NGFW bündelt das, was früher mehrere Geräte/Schritte waren, in einer Plattform:
    • App-ID: erkennt Anwendungen unabhängig vom Port, statt nur nach IP/Port zu filtern
    • TLS/SSL-Inspection, weil praktisch aller Traffic heute verschlüsselt ist
    • IPS/Sandboxing gegen bekannte und unbekannte Bedrohungen
    • zunehmend KI-gestützte Anomalieerkennung
  • NGFW ist heute der De-facto-Standard in Unternehmen. Sie ersetzt nicht die Konzepte aus den vorherigen Abschnitten, sondern bündelt sie in einer Plattform.

Zero Trust / ZTNA

  • Zero Trust bedeutet: keine Instanz im Netzwerk wird automatisch als vertrauenswürdig behandelt, nur weil sie sich am „richtigen" Ort befindet (z.B. im internen Netz). Jede einzelne Verbindung muss sich ausweisen.
  • Der Bruch mit dem klassischen Perimeter-Denken: Es gibt kein pauschal vertrauenswürdiges „internes Netz“ mehr.
  • Jede Verbindung wird einzeln anhand von Identität, Gerätezustand und Kontext autorisiert — unabhängig davon, wo der Client sitzt.
  • Deny-by-default: ohne explizite Erlaubnis keine Verbindung.
  • Zugriff ist immer anwendungsspezifisch, nie netzwerkweit (z.B. Zugriff auf genau eine interne App, nicht auf das ganze Subnetz).
  • Löst zunehmend klassische VPN-Zugänge als Angriffsfläche ab — ein kompromittiertes VPN gibt sonst Zugriff aufs ganze Netz, ein kompromittierter ZTNA-Zugang nur auf die eine freigegebene Anwendung.
  • ZTNA (Zero Trust Network Access) ist die technische Umsetzung von Zero Trust: der Zugriffsweg, über den diese Prüfung pro Verbindung tatsächlich stattfindet.
  • ZTNA ist mittlerweile Standardbestandteil in Enterprise-NGFWs — es ersetzt Screened Subnet/DMZ nicht, ergänzt sie aber um eine Prüfung pro Zugriff statt pro Netzzone.

Cloud-native Security / SASE

  • SASE (Secure Access Service Edge) beschreibt, wie die klassische Firewall-Hardware im eigenen Rechenzentrum durch einen Sicherheits-Stack in der Cloud ersetzt wird.
  • Egal ob Remote-Nutzer oder Zweigstelle: der Traffic läuft immer zuerst über denselben Cloud-Sicherheitsstack, bevor er sein Ziel erreicht.
  • SASE bündelt vier Bausteine in einem Dienst:
    • SWG (Secure Web Gateway): prüft und filtert ausgehenden Web-Traffic — der Cloud-Nachfolger des klassischen Forward-Proxys.
    • CASB (Cloud Access Security Broker): überwacht die Nutzung von Cloud-Diensten wie Microsoft 365 oder Salesforce, z.B. um zu verhindern, dass Firmendaten in private Cloud-Speicher hochgeladen werden.
    • FWaaS (Firewall-as-a-Service): die klassische Firewall-Funktion (Paketfilter, SPI, NGFW-Features) als gemieteter Cloud-Dienst statt als eigene Hardware im Serverraum.
    • ZTNA: siehe vorheriger Abschnitt — die identitätsbasierte Zugriffskontrolle pro Verbindung.
  • Ein Enforcement-Punkt für alle Standorte statt Hardware pro Standort — Policy folgt dem Nutzer, nicht dem Netzwerkstandort.
  • Besonders relevant für Unternehmen mit vielen Standorten oder viel Remote-Arbeit.