Firewall Topologien: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 14: Zeile 14:
 
*Nicht alle Sicherheitsrichtlinien lassen sich durchsetzen
 
*Nicht alle Sicherheitsrichtlinien lassen sich durchsetzen
 
*kein Zustand, keine Anwendungserkennung → siehe Stateful Packet Inspection und NGFW
 
*kein Zustand, keine Anwendungserkennung → siehe Stateful Packet Inspection und NGFW
[[Bild:paketfilter1.png]]
 
 
{{#drawio:paketfilter}}
 
{{#drawio:paketfilter}}
  

Version vom 27. Juli 2026, 09:00 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
  • weit verbreitet
  • 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.

Dualhomedhost1.png

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äß.

StatefullPacketInspection.png

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.

Dmz screened subnet.png

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.

Ngfw.png

Zero Trust / ZTNA

  • 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.
  • Löst zunehmend klassische VPN-Zugänge als Angriffsfläche ab.
  • 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.

Zerotrust.png

Cloud-native Security / SASE

  • Die Firewall wandert aus dem eigenen Rechenzentrum in die Cloud.
  • Egal ob Remote-Nutzer oder Zweigstelle: der Traffic läuft über denselben Cloud-Sicherheitsstack, bevor er sein Ziel erreicht.
  • SASE bündelt Secure Web Gateway (SWG), CASB, Firewall-as-a-Service (FWaaS) und ZTNA.
  • 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.

Sase.png


Eine interaktive Version dieser Architekturen mit anklickbaren Paketfluss-Animationen (erlaubt/blockiert) gibt es unter firewall-topologien.html auf labs.xinux.net.