Das Gastgerät braucht Internet, aber keinen Dateiserver.
Ein Besucher verbindet sein Notebook mit dem Gäste-WLAN. Webseiten sollen funktionieren, der interne Dateiserver und die Verwaltungsoberflächen jedoch unerreichbar bleiben. Ein eigenes WLAN mit anderem Namen reicht dafür nicht. Entscheidend ist, welche Wege das Gerät benutzen kann und welche Kommunikation auf diesen Wegen erlaubt wird. Eine Firewall setzt solche Entscheidungen technisch durch: Sie lässt definierten Verkehr zu und unterbindet den übrigen.
Die erste Frage lautet deshalb nicht „Welches Produkt installieren wir?“, sondern „Wer braucht welchen Dienst auf welchem System?“. Aus „Gäste brauchen Internet“ wird beispielsweise: Gäste dürfen den vorgesehenen DNS-Resolver benutzen und Webverbindungen zu öffentlichen Zielen aufbauen. Sie brauchen weder SMB zum Dateiserver noch SSH zum Router. Die Regeln beschreiben einen nachvollziehbaren Bedarf. Das Prinzip Least Privilege, also minimale Berechtigung, begrenzt ihn auf notwendige Quellen, Ziele, Dienste und gegebenenfalls Zeiten.
Eine Firewall entscheidet über Erreichbarkeit. Ob ein Benutzer eine Datei lesen darf, entscheidet zusätzlich der Dateiserver. Ob eine Webseite vertrauenswürdig ist, ergibt sich ebenfalls nicht aus einer erlaubten Verbindung. Netzwerkzugriff, Anmeldung und Berechtigungen ergänzen sich. Die Grundlagen zu IPv4-Adressen, IPv6 und Routing helfen dabei, diese Ebenen auseinanderzuhalten.
Host-Firewall und Netzwerk-Firewall schützen unterschiedliche Wege.
Eine Host-Firewall läuft auf dem einzelnen Rechner. Sie kann eingehende Verbindungen zu diesem Host sowie von ihm ausgehenden Verkehr filtern. Bei manchen Produkten kommen Regeln für Anwendungen oder Benutzer hinzu. Eine Netzwerk-Firewall kontrolliert Verkehr zwischen Netzbereichen, beispielsweise zwischen Internet, Gästen und Servern. Sie sieht aber nur die Pakete, die tatsächlich durch sie hindurchlaufen.
Zwei Rechner im selben Ethernet-Segment können direkt miteinander sprechen. Ihre Pakete durchqueren dann nicht automatisch das zentrale Gateway. Eine restriktive Internet-Firewall schützt diesen lokalen Weg deshalb nicht. Hier helfen passende Segmentierung, Schutz auf den Endgeräten und bei WLAN-Gästen gegebenenfalls Client-Isolation. Ein zweiter Netzanschluss, ein unkontrolliertes VPN oder falsch gesetzte Switchports können einen vorgesehenen Kontrollpunkt umgehen.
Auch die Richtung hängt vom betrachteten Gerät ab. Die Webanfrage des Gastnotebooks ist dort ausgehend. Am Gateway kommt sie am Gastinterface an und wird über ein anderes Interface weitergeleitet. Eine Anfrage an die Verwaltungsoberfläche des Gateways endet dagegen auf der Firewall selbst. Regeln für lokalen Eingang und Regeln für Weiterleitung sind getrennt zu planen. Eine Freigabe im falschen Regelbereich kann wirkungslos sein oder versehentlich die Firewallverwaltung öffnen.
Ein Paketfilter liest Merkmale, kein Sicherheitsversprechen.
Ein klassischer Paketfilter betrachtet unter anderem Quell-IP, Ziel-IP, Transportprotokoll und bei TCP oder UDP die Ports. Bei einer HTTPS-Verbindung ist der Zielport häufig TCP 443; HTTP/3 verwendet gewöhnlich UDP 443 für QUIC. Der Client benutzt auf seiner Seite typischerweise einen dynamischen Quellport. „Port 443 erlauben“ muss deshalb präzisieren: an welchem Ziel, in welcher Richtung und für welches Protokoll?
Ein Port bezeichnet außerdem keine geprüfte Anwendung. Auf TCP 443 kann auch ein anderer Dienst lauschen. Ein einfacher Paketfilter erkennt weder jede Schadsoftware noch zuverlässig den fachlichen Inhalt verschlüsselter Kommunikation. Produkte mit Proxy- oder Anwendungsfunktionen können weitergehende Prüfungen durchführen; ihre Möglichkeiten hängen von Protokoll, Verschlüsselung und Konfiguration ab. Eine TLS-Entschlüsselung zur Inhaltsprüfung wäre eine eigene Architekturentscheidung mit zusätzlichen Vertrauens- und Datenschutzfragen.
Default Deny bedeutet: Was keine passende Freigabe besitzt, wird standardmäßig abgewiesen. Das erleichtert die Begründung neuer Zugriffe. Eine Denylist erlaubt dagegen grundsätzlich alles und verbietet einzelne bekannte Fälle. In unserem Beispiel wird jede neue Freigabe mit Zweck, Verantwortlichem und Prüftermin dokumentiert. Eine vorübergehende Ausnahme braucht ein Enddatum; andernfalls wird aus der einmaligen Hilfe schnell ein dauerhafter, vergessener Zugang.
Stateful Filtering ordnet Antworten einer erlaubten Verbindung zu.
Eine zustandsbehaftete Firewall führt eine Zustandstabelle. Bei TCP beobachtet sie den Verbindungsaufbau und weitere Zustandsmerkmale. Sie kann Antwortpakete einer erlaubten Verbindung zuordnen. Deshalb braucht die Rückrichtung normalerweise keine allgemeine spiegelbildliche Freigabe „Internet darf zum Gastnetz“. Eine solche Regel würde neue Verbindungen erlauben, obwohl nur Antworten erwünscht sind.
UDP besitzt keinen TCP-Handshake. Trotzdem kann die Firewall anhand von Adressen, Ports, Richtung und Zeitfenster einen zustandsähnlichen Eintrag führen. Bei einer DNS-Anfrage wird so eine zeitnah passende Antwort erkannt. Das macht UDP nicht verbindungsorientiert und beweist nicht, dass der Inhalt ungefährlich ist. Nach einem Timeout kann die Zuordnung fehlen. Auch ICMP-Fehlermeldungen lassen sich teilweise einer bestehenden Kommunikation zuordnen; Produkte nennen das häufig RELATED.
Stateful Filtering setzt voraus, dass die Firewall die relevanten Pakete sieht. Bei asymmetrischem Routing läuft die Anfrage durch Firewall A, die Antwort jedoch durch Firewall B. Ohne passende Synchronisierung kann B die Antwort verwerfen. Ein scheinbarer Regeldefekt ist dann ein Wegeproblem. Änderungen an Freigaben wirken außerdem je nach System zunächst nur auf neue Verbindungen: Ein vorhandener Zustand kann weiterleben. Bei akutem Zugriffsentzug muss deshalb auch der Umgang mit bestehenden Zuständen ausdrücklich geprüft werden.
Ein nachvollziehbares Regelwerk für Gäste.
Das folgende Papierlabor verwendet drei Dokumentationsnetze: Gäste 192.0.2.0/24, Büro 198.51.100.0/24 und Server 203.0.113.0/24. Resolver ist 203.0.113.53, Dateiserver 203.0.113.20. Diese Adressen dienen ausschließlich der Erklärung und werden nicht als reale Netze eingerichtet. Das Zielobjekt „Internet“ bedeutet hier ausdrücklich öffentliche Ziele außerhalb aller internen und sonst gesperrten Bereiche; es ist kein Alias für „beliebig“.
Für diesen vereinfachten Filter gilt First Match: Die erste passende terminale Regel entscheidet. Ein späteres Verbot repariert keine frühere zu breite Freigabe. Reale Systeme können zusätzliche Tabellen, Zonen, Prioritäten oder nicht abschließende Aktionen besitzen; deren Auswertungsmodell muss vor Änderungen bekannt sein. Die Tabelle zeigt weitergeleiteten Verkehr. Regeln für Firewallverwaltung und lokalen Betrieb sind separat erforderlich.
| Nr. | Quelle | Ziel | Dienst oder Zustand | Aktion |
|---|---|---|---|---|
| 1 | alle | alle | ungültiger Zustand | verwerfen |
| 2 | passende Gegenstelle | bestehende Gegenstelle | ESTABLISHED / passende RELATED-Fehler | erlauben |
| 3 | Gastnetz | Resolver 203.0.113.53 | neues DNS, UDP/TCP 53 | erlauben |
| 4 | Gastnetz | alle internen Zonen | alle übrigen neuen Zugriffe | verwerfen |
| 5 | Gastnetz | Internet-Zielobjekt | neues Web, TCP 80/443, UDP 443 | erlauben |
| 6 | Büronetz | Dateiserver 203.0.113.20 | neues SMB, TCP 445 | erlauben |
| Standard | alle | alle | keine explizite Regel passt | Default Deny: verwerfen |
Die DNS-Ausnahme steht vor dem internen Verbot, weil der vorgesehene Resolver im Servernetz liegt. Zum Dateiserver passt dagegen Regel 4; die Webfreigabe wird nicht erreicht. Eine neue Verbindung vom Internet zu einem Gast findet keine Freigabe und endet in Default Deny. Regel 6 erlaubt Bürogeräten einen bestimmten Dateidienst, aber nicht automatisch Verwaltung oder Datenbanken auf demselben Server.
Das ist bewusst keine vollständige produktive Policy: Adressvergabe, notwendige Zeitsynchronisierung, lokale Kontrollprotokolle, erlaubte Diagnose und konkrete Betriebsdienste müssen anhand der Architektur hinzukommen. Die Zustandserkennung benötigt zudem Schutz gegen gefälschte Quellen an ungeeigneten Eingängen. Eine aus dem Gastinterface eintreffende Adresse des Servernetzes darf nicht als Serveridentität gelten. Die Quellprüfung gehört zum Entwurf, nicht zum Vertrauen in eine frei gesetzte IP-Adresse.
VLANs trennen Segmente; Regeln bestimmen die Übergänge.
Ein VLAN bildet einen eigenen Layer-2-Bereich. Verkehr zu einem anderen IP-Netz braucht normalerweise Routing. Wird Inter-VLAN-Routing auf einem Layer-3-Switch ohne passende Filter aktiviert, können die getrennten VLANs trotzdem umfassend miteinander kommunizieren. Segmentierung wird erst mit kontrollierten Übergängen zur Sicherheitsmaßnahme. Nicht jede Route muss über dieselbe physische Appliance führen; entscheidend ist eine wirksame, nachvollziehbare Policy auf jedem erlaubten Weg.
NAT beziehungsweise NAPT übersetzt Adressen und gegebenenfalls Ports. Es beschreibt keine vollständige Sicherheitsrichtlinie. Dass ein Heimrouter unerwartete eingehende IPv4-Pakete häufig nicht zuordnen kann, ist kein Ersatz für bewusst definierte Filter. Portweiterleitungen, automatisch angelegte Zuordnungen und ausgehende Verbindungen verändern die Erreichbarkeit. Bei IPv6 sind global routbare Adressen üblich; eine zustandsbehaftete Firewall kann trotzdem neue unerwünschte Eingänge sperren, ganz ohne Adressübersetzung.
IPv6 und ICMP brauchen eine eigene, funktionierende Policy.
Ein nur für IPv4 geschlossenes Netz ist nicht automatisch für IPv6 geschlossen. Bei Dual Stack besitzt ein Gerät zwei Wegefamilien. Zonen, Adressobjekte und Dienstfreigaben müssen für beide konsistent geplant werden. Dabei werden IPv4-Regeln nicht einfach blind kopiert: IPv6 hat andere Kontrollmechanismen und Erweiterungsheader. Auch ein großer IPv6-Adressraum ersetzt keine Zugriffskontrolle.
ICMPv6 ist für regulären IPv6-Betrieb unverzichtbar. Neighbor Solicitation und Neighbor Advertisement unterstützen die Nachbarerkennung auf dem lokalen Link. Router Advertisements und Router Solicitations gehören je nach Rolle zur Routerentdeckung. Diese lokalen Nachrichten sollen nicht beliebig durch Router ins Internet weitergeleitet werden; Hostfilter müssen sie im passenden lokalen Kontext dennoch ermöglichen. Zulässige Absender, Interface, Nachrichtentyp und Scope sind Teil der Entscheidung.
Daneben müssen notwendige Fehlermeldungen funktionieren, insbesondere Packet Too Big für die Pfad-MTU-Ermittlung. Ein pauschales Blockieren kann Verbindungen verursachen, die sich aufbauen, aber bei größeren Übertragungen hängen. Auch bei IPv4 sind passende ICMP-Fehler für Diagnose und Path MTU Discovery relevant. Echo-Anfragen für Ping sind eine getrennte Policyfrage. Weder „alles ICMP sperren“ noch „alles ICMPv6 überall erlauben“ ist eine tragfähige Regel. Der ICMP-Artikel erklärt die Unterschiede genauer.
Logs und Tests machen Entscheidungen überprüfbar.
Bei einer Störung werden zuerst Quelle, Ziel, Protokoll, Richtung und Zeitpunkt festgehalten. Danach wird geprüft: Welcher Weg wird tatsächlich benutzt? Welcher Regelzähler steigt? Gibt es einen passenden Zustand? Ein Logeintrag sollte die entscheidende Regel sowie Adressen, Ports beziehungsweise ICMP-Typ und Zeit erkennen lassen. Protokollierung braucht begrenzte Mengen, geschützten Zugriff, passende Aufbewahrung und tatsächliche Auswertung. Ein volllaufender Datenträger oder dauerhaftes Lograuschen hilft niemandem.
Geprüft werden erlaubte und verbotene Fälle: Gast-Webzugriff, DNS am vorgesehenen Resolver, verweigerter Dateiserverzugriff und verweigerte neue Eingänge. Danach folgen die IPv6-Entsprechungen und notwendige Kontrollnachrichten. Ein erfolgreicher Ping beweist keinen funktionierenden Dateidienst. Ein Timeout beweist umgekehrt keine Firewallblockade; auch Routing, Listener oder Namensauflösung können fehlen. Der Artikel zur Linux-Serverdiagnose liefert dafür eine sinnvolle Reihenfolge.
Vor echten Änderungen sind Konfigurationssicherung, dokumentierter Rückweg und ein unabhängiger Administrationszugang nötig. Die einzige SSH-Sitzung ist kein belastbarer Notfallplan. Ungeprüfte „temporäre“ Any-to-any-Regeln, eine ungeschützte Verwaltungsoberfläche und vergessene IPv6-Freigaben gehören zu den typischen Fehlern. Dieses Beispiel wird nur auf Papier ausgewertet; es enthält keine Befehle, die eine bestehende Firewall verändern.
Eine korrekt konfigurierte Firewall verhindert schließlich nicht jeden Angriff: Ein kompromittiertes Bürogerät kann eine erlaubte SMB-Verbindung missbrauchen, eine bösartige Webseite kann über erlaubtes HTTPS erreichbar sein. Updates, sichere Anmeldung, Rechte, wiederherstellbare Backups und eine Reaktion auf Vorfälle bleiben erforderlich. Ein VPN liefert einen geschützten Zugangsweg; die Zugriffsregeln dahinter bleiben eine eigene Aufgabe.
Zwei Regelentscheidungen selbst prüfen.
Aufgabe 1: Jemand verschiebt die Webfreigabe nach oben und ändert ihr Ziel von „Internet-Zielobjekt“ auf „alle“. Unterhalb steht weiterhin das Verbot „Gäste → interne Zonen“. Kann ein Gast nun eine interne Webverwaltung auf TCP 443 erreichen?
Lösung: Die frühere Freigabe entscheidet
Ja, im beschriebenen First-Match-Modell passt bereits die breite Webfreigabe. Die spätere Sperre wird nicht mehr ausgewertet. Das betrifft nicht automatisch SMB auf TCP 445, aber sehr wohl interne Webdienste. Die Freigabe muss wieder auf zulässige öffentliche Ziele begrenzt und die Reihenfolge nachvollziehbar festgelegt werden. Anschließend sind ausdrücklich auch verbotene interne Webzugriffe zu prüfen. Eine korrekt aussehende Sperrzeile allein beweist keinen wirksamen Schutz.
Aufgabe 2: Gäste können eine IPv6-Webseite öffnen. Kleine Antworten kommen an, ein größerer Download hängt. Alle ICMPv6-Nachrichten wurden als vermeintlich unnötige Diagnose gesperrt. Sollte stattdessen der Rückverkehr pauschal erlaubt werden?
Lösung: Kontrollnachrichten und Zustand unterscheiden
Nein. Zuerst wird der konkrete Pfad geprüft; das Muster passt unter anderem zu gestörter Pfad-MTU-Ermittlung. Notwendige Packet-Too-Big-Meldungen müssen die betroffenen Teilnehmer erreichen können. Die Policy braucht außerdem passende lokale Neighbor-Discovery-Nachrichten. Das ist keine allgemeine Freigabe neuer Internetverbindungen zum Gastnetz. Zustandserkennung, notwendige Fehler und lokale Kontrollprotokolle werden gezielt geprüft. Das Fehlerbild allein beweist die Ursache noch nicht; andere MTU- oder Wegefehler bleiben möglich.
Quellen und fachlicher Stand.
Fachlich geprüft am . Herstellerneutrales Papiermodell mit ausdrücklich definierter First-Match-Auswertung, keine produktive Konfigurationsvorlage. Bezugsstand des BSI-Bausteins: Edition 2023. Der direkte BSI-PDF-Abruf war bei der Recherche gesperrt; offizielle indexierte Auszüge waren verfügbar. Die Grundlagen wurden mit den folgenden Primärquellen abgeglichen.
- BSI: NET.3.2 Firewall, Edition 2023, insbesondere A2/A3 zu Regeln und zustandsbehafteter Filterung sowie A6 zum Managementzugang.
- NIST SP 800-41 Revision 1: Guidelines on Firewalls and Firewall Policy, September 2009: Firewallarten, Policy, Grenzen und Betrieb. Historische Grundlagenquelle, keine aktuelle Produktempfehlung.
- RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls, Mai 2007: rollenabhängige Filterung lokaler Nachrichten und Transitverkehr.
- RFC 8201: Path MTU Discovery for IP version 6, Juli 2017: Bedeutung von Packet Too Big.
- RFC 4861: Neighbor Discovery for IP version 6, September 2007, mit den auf der RFC-Informationsseite verzeichneten Aktualisierungen: lokale Nachbar- und Routerentdeckung.