Firewall Topologien: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(29 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
=Einfacher Paketfilter=
 
=Einfacher Paketfilter=
*Einfacher Paktetfilter wird das Interne Netz mit einem Router an ein öffentliches Netz angebunden Der Router arbeitet aber selektiv.
+
*Einfacher Paketfilter: das interne Netz wird mit einem Router an ein öffentliches Netz angebunden. Der Router arbeitet aber selektiv.
*Das bedeutet das nur bestimmte Arten von Pakteten das passieren erlaubt wird anderen wird es nicht gewährt.
+
*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- Achitektur.
+
*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==
 
==Vorteile der Paketfilterung==
*kann ganzes Netzwerk schützen
+
*kann ganzes Netzwerk schützen
 
*extrem effektiv
 
*extrem effektiv
*weit verbreitet 
+
*schnell, da über die Verbindungen nicht Buch geführt wird
*schnell das über die Verbindungen nicht Buch geführt wird.
+
 
 
==Nachteil==
 
==Nachteil==
*Filterbeschreibungspachen sind nicht perfekt  
+
*Filterbeschreibungen sind nicht perfekt
 
*Router wird belastet
 
*Router wird belastet
*Nicht alle Sicherheitrichtlinen lassen sich durch sezten
+
*Nicht alle Sicherheitsrichtlinien lassen sich durchsetzen
[[Bild:paketfilter1.png]]
+
*kein Zustand, keine Anwendungserkennung → siehe Stateful Packet Inspection und NGFW
=Dual Homed Host=
+
{{#drawio:paketfilter}}
==Grundsätzliches==
+
 
*Auf einem Dual Homed Host laufen sogenannte Proxys(Stellvetretter) Proxy arbeitet auf allen 7 Schichten des ISO/OSI-Models.
+
=Application- und Circuit-Level-Proxys (historisch: Dual Homed Host)=
*Das bedeutet das sie mit dem Anwendungsprotoll in Berührung kommen.  
+
*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 verschiedenen Arten
+
*Es gibt 2 verschiedene Arten:
==Application Level Proxys==
+
**'''Application Level Proxys''' kennen das Anwendungsprotokoll genau (Beispiel: Squid, ein cache-only Nameserver) — vergleichbar mit einem Dolmetscher.
*Diese Proxyarten kennen das Anwednungsprotokoll genau.
+
**'''Circuit Level Proxys''' kennen das Anwendungsprotokoll nicht, sie „quatschen“ alles nur nach oder setzen es um (Beispiel: SOCKS, Delegated) — vergleichbar mit einem Übersetzungsprogramm.
*Beispielsweise  squid aber auch ein chache-only Nameserver kann man als Application Level Proxybezeichnen.
+
*Vorteile: gutes Protokollieren, Caching, anwendungsspezifische Filterung, Authentifikation auf Userebene, kein IP-Forwarding notwendig.
*(~Dolmetscher in der realen Welt)
+
*Nachteile: neuere Protokolle werden nicht unterstützt, verschiedene Proxyserver für verschiedene Dienste notwendig, Clients müssen ihr Verhalten ändern.
==Circuit Level Proxys==
+
*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.
*Diese Proxyarten kennen das Anwednungsprotokoll nicht.
+
{{#drawio:dualhomedhost}}
*Sie „quatschen“ alles nur nach oder setzen es um.
 
*Beispielweise socks oder delegated sind Circuit Level Proxys
 
*(~Übersetzungsprogramm in der realen Welt)
 
==Vorteile==
 
*Gutes Protokollieren  
 
*Caching
 
*Anwendungsspezifische Filterung  
 
*Authetifikation auf Userebene
 
*Kein IP Forwarding notwendig
 
==Nachteile==
 
*Neuere Protokolle werden nicht unterstützt
 
*Verschiedene Proxyserver für verschiedene Dienste notwendig  
 
*Client müssen Verhalten ändern
 
[[Datei:dualhomedhost1.png]]
 
  
=Statefull Packet Inspection=
+
=Stateful Packet Inspection=
*Unter Stateful Packet Inspection (SPI; deutsch Zustandsorientierte Paketüberprüfung) versteht man eine dynamische Paketfiltertechnik,
+
*Unter Stateful Packet Inspection (SPI; deutsch: zustandsorientierte Paketüberprüfung) versteht man eine dynamische Paketfiltertechnik.
*Jedes Datenpaket einer bestimmten aktiven Session zugeordnet wird.
+
*Jedes Datenpaket wird einer bestimmten aktiven Session zugeordnet.
 
*Die Datenpakete werden analysiert und der Verbindungsstatus wird in die Entscheidung einbezogen.
 
*Die Datenpakete werden analysiert und der Verbindungsstatus wird in die Entscheidung einbezogen.
*Es werden die Datenpakete während der Übertragung auf der Vermittlungsschicht analysiert und in dynamischen Zustandstabellen gespeichert.
+
*Die Datenpakete werden während der Übertragung auf der Vermittlungsschicht analysiert und in dynamischen Zustandstabellen gespeichert.
[[Datei:StatefullPacketInspection.png]]
+
*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}}
 +
 
 +
=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}}
  
*[[Architektur mit überwachten Hosts]]
+
=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}}
  
=Architektur mit überwachten Hosts=
+
=Cloud-native Security / SASE=
*[[Architektur mit überwachtem Teilnetz]]
+
*'''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 überwachtem Teilnetz=
+
*Egal ob Remote-Nutzer oder Zweigstelle: der Traffic läuft immer zuerst über denselben Cloud-Sicherheitsstack, bevor er sein Ziel erreicht.
*[[Geteiltes und überwachtes Teilnetz mit Dual-Homed-Host]]
+
*SASE bündelt vier Bausteine in einem Dienst:
=Geteiltes und überwachtes Teilnetz mit Dual-Homed-Host=
+
**'''SWG (Secure Web Gateway)''': prüft und filtert ausgehenden Web-Traffic — der Cloud-Nachfolger des klassischen Forward-Proxys.
*[[Architektur mit zusammengelegtem inneren und äusseren Paketfilter]]
+
**'''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.
=Architektur mit zusammengelegtem inneren und äusseren Paketfilter=
+
**'''FWaaS (Firewall-as-a-Service)''': die klassische Firewall-Funktion (Paketfilter, SPI, NGFW-Features) als gemieteter Cloud-Dienst statt als eigene Hardware im Serverraum.
*[[Architektur mit zusammengelegtem inneren und äusseren Paketfilter und mehreren Grenznetzen]]
+
**'''ZTNA''': siehe vorheriger Abschnitt — die identitätsbasierte Zugriffskontrolle pro Verbindung.
=Architektur mit zusammengelegtem inneren und äusseren Paketfilter und mehreren Grenznetzen=
+
*Ein Enforcement-Punkt für alle Standorte statt Hardware pro Standort — Policy folgt dem Nutzer, nicht dem Netzwerkstandort.
*[[Architektur mit mehreren Grenznetzen]]
+
*Besonders relevant für Unternehmen mit vielen Standorten oder viel Remote-Arbeit.
=Architektur mit mehreren Grenznetzen=
+
{{#drawio:sase}}

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.