Firewall Topologien: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (52 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | + | =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. | |
| − | =Einfacher Paketfilter | + | *Paketfilter arbeitet auf den untersten 4 Schichten der TCP/IP-Architektur. |
| − | *Einfacher | + | *Bis heute die Basis: nftables/iptables und die unterste Schicht jeder modernen Firewall (NGFW) arbeiten nach demselben Prinzip. |
| − | *Das bedeutet | ||
| − | *Paketfilter | ||
==Vorteile der Paketfilterung== | ==Vorteile der Paketfilterung== | ||
| − | *kann ganzes Netzwerk schützen | + | *kann ganzes Netzwerk schützen |
*extrem effektiv | *extrem effektiv | ||
| − | + | *schnell, da über die Verbindungen nicht Buch geführt wird | |
| − | *schnell | + | |
==Nachteil== | ==Nachteil== | ||
| − | * | + | *Filterbeschreibungen sind nicht perfekt |
*Router wird belastet | *Router wird belastet | ||
| − | *Nicht alle | + | *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}} | ||
| − | == | + | =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}} | ||
| + | =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. | ||
| + | *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. | ||
| + | {{#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.







