Firewall, NGFW, WAF: Security-Kontrollen ins OSI-Modell einordnen

Firewall, NGFW, WAF – diese drei Begriffe werden im Alltag oft durcheinandergeworfen, obwohl sie unterschiedliche Security-Kontrollen darstellen und auf verschiedenen Ebenen wirken. Wer Security-Architekturen planen, Incidents schneller diagnostizieren oder Compliance-Anforderungen sauber nachweisen möchte, profitiert davon, Firewall, NGFW und WAF systematisch ins OSI-Modell einzuordnen. Das OSI-Modell liefert eine gemeinsame Sprache, um zu klären, welche Daten eine Kontrolle „sehen“ kann, welche Entscheidungen sie treffen kann und welche Angriffe sie realistisch verhindert – und welche nicht. Genau hier entstehen in der Praxis Missverständnisse: Eine klassische Firewall kann keine Business-Logik verstehen, ein WAF ersetzt keine Netzsegmentierung, und eine NGFW ist nicht automatisch eine „Allzweck-Sicherheitsschicht“. Dieser Artikel zeigt, welche Security-Kontrollen auf welchen OSI-Schichten primär arbeiten, wie sich die Werkzeuge überlappen, welche Telemetrie sinnvoll ist und wie Sie typische Fehlannahmen vermeiden. Das Ziel: klare Erwartungen an Firewall, NGFW, WAF – und eine Architektur, in der Kontrollen sich ergänzen statt sich gegenseitig zu versprechen, was sie technisch nicht leisten können.

Warum das OSI-Modell für Security-Kontrollen so nützlich ist

Security wird häufig in Produkten gedacht („Wir haben doch eine NGFW“), während Angriffe und Störungen in Schichten passieren: Paketverlust und MTU-Probleme sind nicht dasselbe wie TLS-Handshake-Fehler, und beides ist nicht dasselbe wie SQL-Injection. Das OSI-Modell zwingt zur Präzision: Welche Informationen liegen auf welcher Schicht vor? Ein Gerät, das nur Layer 3/4 verarbeitet, kann keine HTTP-Header auswerten. Eine Layer-7-Policy kann dagegen sehr spezifisch sein, ist aber blind für physische Link-Probleme.

• Transparenz: Sie erkennen, welche Kontrolle welchen Teil des Datenpfads abdeckt.
• Grenzen: Sie vermeiden „Schein-Sicherheit“, wenn ein Tool gar nicht die nötigen Signale hat.
• Betriebsfähigkeit: Troubleshooting wird schneller, weil die Fehlersuche schichtweise strukturiert ist.

Begriffsabgrenzung: Firewall, NGFW und WAF in einem Satz

Eine Firewall kontrolliert Verkehr anhand von Netzwerk- und Transportmerkmalen (typisch Layer 3/4), eine NGFW erweitert dies um mehr Kontext (z. B. Applikationserkennung, Benutzerbezug, IPS-Funktionen) und kann stärker in Richtung Layer 7 gehen, und ein WAF fokussiert auf HTTP(S)-Anwendungen (Layer 7) und deren typische Angriffs- und Missbrauchsmuster.

Layer 2 und Layer 3: Netzwerkgrenzen, Segmentierung und Paketfilter-Grundlagen

Auch wenn „Firewall“ meist mit IP (Layer 3) assoziiert wird, beginnen relevante Kontrollen teils früher. Auf Layer 2 geht es um die direkte Nachbarschaft: MAC-Adressen, VLANs, ARP/ND, Switch-Ports. Eine WAF sieht diese Ebene nicht – und eine klassische Firewall in Routed-Position ebenfalls nur indirekt.

Layer-2-nahe Kontrollen und ihre Rolle neben Firewalls

• VLAN- und VRF-Design als erste grobe Segmentierung (Trennung von Broadcast- und Routing-Domains)
• 802.1X/NAC als Zugriffskontrolle „am Port“ (wer darf überhaupt ins Netz?)
• DHCP Snooping/DAI/IP Source Guard zur Reduktion von Spoofing im Access-Bereich

Diese Kontrollen sind keine Firewalls im engeren Sinn, aber sie reduzieren die Angriffsfläche, bevor Traffic überhaupt eine Firewall erreicht. Gerade im Enterprise-Umfeld ist das ein entscheidender Baustein, um laterale Bewegungen einzuschränken.

Layer 3: Klassische Firewall-Domäne

Auf Layer 3 werden Quell- und Ziel-IP, Subnetze, Routing und Netzgrenzen relevant. Hier entfaltet Segmentierung ihren größten Effekt: „Wer darf mit wem sprechen?“ Klassische Paketfilter und viele Stateless-Regeln arbeiten primär auf dieser Ebene.

• Ingress-/Egress-Policies zwischen Zonen, Standorten, Cloud-VPCs/VNETs
• Default-Deny als Sicherheitsprinzip, ergänzt durch explizite Allow-Regeln
• Anti-Spoofing (z. B. uRPF) und Routing-Guardrails als Ergänzung zur Filterlogik

Für ein solides Grundlagenverständnis zu Firewall-Konzepten und Architektur lohnt sich ein Blick in NIST SP 800-41 (Guidelines on Firewalls and Firewall Policy).

Layer 4: Zustandsbezug, Ports, Timeouts und DoS-Schutz

Layer 4 bringt den Verbindungsbezug ins Spiel: TCP/UDP-Ports, Session-States, Handshakes, Timeouts, Retransmissions. Viele betriebliche Probleme, die wie „Security“ wirken, sind in Wahrheit Ressourcen- oder Zustandsprobleme: Connection-Tracking-Tabellen laufen voll, SYN-Floods triggern Schutzmechanismen, oder Idle-Timeouts trennen langlebige Verbindungen.

Stateful Firewalling und Connection Tracking

Stateful Firewalls führen Zustände über Flows. Das ist mächtig, aber endlich: Tabellen haben Limits, und Timeouts sind harte Parameter. Eine wichtige Betriebskennzahl ist die Auslastung der State-Tabelle im Verhältnis zur Kapazität:

$\mathrm{Auslastung}=\frac{\mathrm{aktive} \mathrm{Sessions}}{\max \mathrm{Sessions}}\cdot 100\%$

• Typischer Effekt: Bei hoher Auslastung steigen Drops/Resets, neue Verbindungen scheitern.
• Operatives Risiko: Zu lange Timeouts binden Ressourcen, zu kurze Timeouts erzeugen „sporadische“ Abbrüche.
• Abgrenzung zur WAF: Ein WAF sieht meist nur HTTP(S) und nicht den vollständigen L4-State des Netzpfads.

NGFW: Warum „Next-Gen“ nicht nur Marketing ist – aber auch kein Wundermittel

Eine NGFW erweitert klassische Firewall-Funktionen um Kontext, Erkennung und teils tiefe Inspektion. Typische Features sind Applikationsidentifikation (auch wenn Ports „anders“ genutzt werden), integriertes Intrusion Prevention (IPS), URL-Filter, Malware-Schutz, TLS-Inspection (je nach Einsatz) sowie Benutzer- oder Gerätebezug durch Integration in Identity-Systeme.

Welche OSI-Schichten eine NGFW realistisch abdeckt

• Layer 3/4: wie klassische Firewalls (IP, Ports, Zonen, State)
• Layer 7 (teilweise): Applikationserkennung, Protokollvalidierung, IPS-Signaturen
• Layer 6 (optional): TLS-Inspection/Decryption, wenn organisatorisch und technisch umgesetzt

Wichtig ist das „teilweise“: NGFW-„App-ID“ ist oft heuristisch und kann durch Verschleierung, neue Protokollvarianten oder QUIC/TLS-Encapsulation weniger zuverlässig werden. Für Protokollstandards und deren Entwicklung ist der RFC Editor eine hilfreiche Referenz, um Erwartungen an Erkennung und Parsing einzuordnen.

WAF: Layer-7-Schutz für Webanwendungen und APIs

Ein Web Application Firewall (WAF) ist spezialisiert auf HTTP(S) und typische Webangriffe. Damit arbeitet ein WAF klar auf Layer 7 und (durch TLS) auch in der Nähe von Layer 6: Entweder terminiert er TLS selbst oder erhält bereits entschlüsselten Traffic von einem Reverse Proxy/Load Balancer. Das macht den WAF extrem effektiv gegen bestimmte Klassen von Angriffen – aber er ist kein Ersatz für Netzwerksegmentierung oder L4-DDoS-Schutz.

Was ein WAF gut kann

• Erkennen und blockieren typischer Webangriffe (z. B. Injection-Muster, Traversal, Protokollanomalien)
• Regelwerke wie Managed Rules, Signaturen und Verhaltensprofile (je nach Produkt)
• Schutz für APIs durch Schema-/Header-Validierung, Rate Limiting, Bot- und Abuse-Mitigation

Eine praxisnahe Orientierung zu Webangriffen und Schutzmaßnahmen bietet die OWASP Top 10, die häufige Risiken in Webanwendungen strukturiert beschreibt.

Was ein WAF nicht kann (und warum das wichtig ist)

• Keine Sicht auf reines Layer-3/4-Routing, MTU, ECMP, NAT-Artefakte, Link-Probleme
• Kein Ersatz für interne Ost-West-Segmentierung, wenn der Angriff nicht über HTTP läuft
• Begrenzte Wirkung bei End-to-End-Verschlüsselung, wenn keine Entschlüsselung an der WAF möglich ist

TLS und Verschlüsselung: Wo Firewall/NGFW/WAF an Grenzen stoßen

Verschlüsselung verschiebt die Sichtbarkeit: Was nicht entschlüsselt werden kann, kann nicht auf Anwendungsebene geprüft werden. Das betrifft NGFW- und WAF-Funktionen gleichermaßen. Die zentrale Designfrage lautet: Wo wird TLS terminiert, und welche Kontrolle erhält entschlüsselten Traffic? Je nach Architektur kann das am Edge (CDN/WAF), am Load Balancer, am API-Gateway oder erst am Service passieren.

• TLS-Termination am Edge: WAF kann Inhalte prüfen, aber interne Segmente brauchen weiterhin L3/L4-Policies.
• End-to-End mTLS: Starke Identität zwischen Services, aber Middleboxes sehen weniger – Policies müssen näher an die Anwendung.
• TLS-Inspection: Mehr Sichtbarkeit für NGFW, aber höhere Komplexität, Datenschutz- und Compliance-Fragen.

Für sichere TLS-Konfigurationen und typische Fallstricke ist die OWASP TLS Cheat Sheet eine nützliche Referenz.

Praktische OSI-Einordnung: Welche Kontrolle entscheidet worüber?

Die entscheidende Frage ist nicht „Welches Produkt haben wir?“, sondern „Welche Entscheidung trifft welche Kontrolle – und auf Basis welcher Daten?“ In der Praxis lassen sich drei Policy-Ebenen unterscheiden: Netzwerkpfad (L3), Verbindungszustand (L4) und Anwendungssemantik (L7).

• Firewall (klassisch): IP/Subnetze, Ports, Zonen, State (L3/L4) – stark bei Segmentierung und Basisschutz.
• NGFW: zusätzlich App-Kontext, IPS, Benutzerkontext (L3–L7) – stark bei kontrollierter Internet-/WAN-Kante und zentralen Übergängen.
• WAF: HTTP(S)-Semantik, Parameter, Header, API-Regeln (L7) – stark an Web- und API-Eingangspunkten.

Typische Fehlannahmen – und die korrekte Zuordnung im OSI-Modell

• „Wir haben eine WAF, also sind APIs sicher.“ Ein WAF schützt HTTP-Schichten, nicht Identitäts- und Berechtigungslogik. AuthZ gehört in API-Gateway und Service.
• „NGFW erkennt jede Anwendung zuverlässig.“ Erkennung hängt von Sichtbarkeit und Protokollvarianten ab; QUIC und Ende-zu-Ende-TLS reduzieren Semantik.
• „Firewall-Regeln sind gleich Security.“ Ohne saubere Zonenmodelle, Egress-Strategie und Monitoring werden Regeln schnell zu Wildwuchs.
• „TLS löst alles.“ TLS löst Vertraulichkeit und Integrität, nicht Missbrauch, nicht Autorisierung und nicht Verfügbarkeit.

Telemetrie und Logging: Welche Daten Sie pro Kontrolle brauchen

Ohne messbare Signale wird jede Kontrolle zur Blackbox. Entscheidend ist, Logs und Metriken so zu wählen, dass sie Incident-Analysen unterstützen und Policies überprüfbar bleiben. Für Firewall/NGFW/WAF sind dabei drei Fragen leitend: Was wurde erlaubt/gebockt? Warum? Mit welchem Kontext?

Firewall/NGFW-Telemetrie

• Allow/Deny-Logs mit 5-Tuple (Src/Dst IP, Src/Dst Port, Protokoll) und Zone/Interface
• State-Table-Auslastung, Drops, Retransmissions-Indikatoren (je nach Plattform)
• NAT-Übersetzungen, Timeout-Events, Resource-Limits (CPU, Memory, Session-Limits)
• Policy-Hit-Counter zur Regelbereinigung und zur Vermeidung ungenutzter Ausnahmen

WAF-Telemetrie

• HTTP-Metadaten (Methode, Pfad, Statuscodes, Header-Klassen) und Regel-ID/Action
• Rate-Limit-Events, Bot-Signale, Anomalie-Scores (je nach Engine)
• False-Positive-Tracking (z. B. per Sampling) und sichere Exception-Prozesse

Architektur-Patterns: Wo Firewall, NGFW und WAF typischerweise platziert werden

Die Platzierung entscheidet über Wirkung und Nebenwirkungen. Eine Kontrolle am falschen Ort erzeugt oft Komplexität ohne Sicherheitsgewinn. Typische Patterns lassen sich sauber über OSI-Schichten begründen.

• Perimeter/Edge: DDoS-Schutz, WAF/CDN, dann NGFW/Firewall für Übergänge in interne Zonen
• Rechenzentrum/Backbone: Segmentierungs-Firewalls oder verteilte Policy (z. B. Security Groups/ACLs) zwischen kritischen Zonen
• Cloud: Security Groups/NACLs (L3/4) plus WAF/API-Gateway (L7) je nach Exposure
• Ost-West: Mikrosegmentierung (host-/workload-nah) kombiniert mit mTLS und service-naher Autorisierung

Policy-Design ohne Wildwuchs: Regeln wartbar halten

Je leistungsfähiger ein Tool ist, desto größer ist die Gefahr, dass Policies unkontrolliert wachsen. Wartbare Security entsteht durch klare Modelle, nicht durch endlose Ausnahme-Listen. Bewährt haben sich wenige Grundprinzipien, die unabhängig vom Hersteller funktionieren.

• Zonenmodell zuerst: Definieren Sie wenige, stabile Zonen und deren erlaubte Kommunikationsrichtungen.
• Least Privilege mit Egress: Egress ist oft die vergessene Seite – dabei entscheidet er über Datenabfluss und Malware-Kommunikation.
• Regel-Hygiene: Nutzen Sie Hit-Counter und entfernen Sie tote Regeln; dokumentieren Sie Ausnahmen mit Owner und Ablaufdatum.
• Trennung der Verantwortlichkeiten: Netzwerksegmentierung (L3/4) und Applikationsautorität (L7) dürfen nicht in einem einzigen Team „verschwimmen“.

Zusammenspiel statt Ersatz: Eine pragmatische Zuordnung nach Schicht und Risiko

Im stabilen Betrieb ergänzen sich Firewall, NGFW und WAF, statt sich gegenseitig zu ersetzen. Ein praktikabler Ansatz ist, Kontrollen entlang des Risikos und der Sichtbarkeit zu staffeln: Grobe, robuste Kontrollen niedrig in den Schichten (Segmentierung, State, Rate Limits) und präzise, semantische Kontrollen dort, wo der Kontext vorliegt (HTTP, API, AuthZ). Wer diese Zuordnung konsequent einhält, reduziert Fehlalarme, vermeidet blinde Flecken und kann Incidents schneller erklären – weil klar ist, welche Schicht welche Entscheidung getroffen hat.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.