# 11.2 Firewall-Regeln und Regelwerke Firewall-Regeln bestimmen, welcher Netzwerkverkehr erlaubt oder blockiert wird. Eine Firewall-Regel beantwortet im Kern diese Fragen: Wer möchte kommunizieren? Mit wem? Über welches Protokoll? Über welchen Port? In welche Richtung? Aus welcher Zone? In welche Zone? Soll der Verkehr erlaubt oder blockiert werden? Merksatz: Firewall-Regeln steuern, wer mit wem über welchen Dienst kommunizieren darf. --- **Warum sind Firewall-Regeln so wichtig?** Eine Firewall ist nur so gut wie ihr Regelwerk. Wenn Regeln zu offen sind, entsteht ein Sicherheitsrisiko. Wenn Regeln zu streng oder falsch sind, funktionieren Dienste nicht. Beispiele: Webserver ist nicht erreichbar, weil TCP 443 blockiert wird. Datenbank ist zu offen erreichbar, weil zu viele Quellen erlaubt sind. Adminzugang ist aus dem Internet erreichbar, weil eine alte Testregel vergessen wurde. Merksatz: Firewall-Regeln müssen sicher und funktionsfähig sein. --- **Bestandteile einer Firewall-Regel** Eine typische Firewall-Regel enthält: - Aktion - Quelle - Ziel - Dienst - Protokoll - Port - Richtung - Zone oder Interface - Kommentar - Logging - Zeitplan - Priorität oder Reihenfolge Beispiel: Aktion: Erlauben Quelle: Admin-Netz Ziel: Webserver in DMZ Dienst: SSH TCP 22 Richtung: LAN → DMZ Merksatz: Eine Firewall-Regel braucht Quelle, Ziel, Dienst und Aktion. --- **Aktion** Die Aktion sagt, was mit passendem Verkehr passieren soll. Typische Aktionen: | Aktion | Bedeutung | |---|---| | Allow | erlauben | | Deny | blockieren | | Drop | still verwerfen | | Reject | aktiv ablehnen | | Log | protokollieren | | NAT | übersetzen oder weiterleiten | Merksatz: Aktion = Was macht die Firewall mit dem Verkehr? --- **Quelle** Die Quelle beschreibt, woher der Verkehr kommt. Beispiele: - einzelne IP-Adresse - Subnetz - Sicherheitszone - Interface - Benutzergruppe - VPN-Gruppe - Hostobjekt Beispiel: Quelle: 192.168.10.0/24 bedeutet: alle Geräte aus diesem Subnetz. Merksatz: Quelle = Wer startet die Verbindung? --- **Ziel** Das Ziel beschreibt, wohin der Verkehr gehen soll. Beispiele: - einzelner Server - Subnetz - DMZ-Zone - Internet - Servergruppe - Datenbankserver - Reverse Proxy Beispiel: Ziel: 192.168.20.10 bedeutet: genau dieser Zielhost. Merksatz: Ziel = Welches System soll erreicht werden? --- **Dienst** Der Dienst beschreibt, welche Anwendung oder welcher Port verwendet wird. Beispiele: HTTP HTTPS DNS SSH RDP SMB SMTP LDAP NTP Ein Dienstobjekt besteht meist aus: Protokoll plus Port Beispiel: HTTPS: TCP 443 Merksatz: Dienst = Protokoll und Port des gewünschten Verkehrs. --- **Protokoll** Das Protokoll beschreibt, ob zum Beispiel TCP, UDP oder ICMP verwendet wird. Beispiele: | Protokoll | Beispiel | |---|---| | TCP | HTTP, HTTPS, SSH, SMB | | UDP | DNS, DHCP, NTP, SNMP | | ICMP | Ping, Fehlermeldungen | | ESP | IPsec | | GRE | bestimmte Tunnel | Merksatz: Port allein reicht nicht, das Transportprotokoll muss auch stimmen. --- **Port** Der Port gehört zur Transportschicht. Beispiele: | Dienst | Port | |---|---:| | HTTP | TCP 80 | | HTTPS | TCP 443 | | SSH | TCP 22 | | RDP | TCP 3389 | | DNS | UDP/TCP 53 | | NTP | UDP 123 | | SMB | TCP 445 | Wichtig: TCP 53 und UDP 53 sind nicht dasselbe. TCP 443 und UDP 443 sind nicht dasselbe. Merksatz: Port immer zusammen mit TCP oder UDP betrachten. --- **Richtung** Die Richtung beschreibt, von welcher Zone oder welchem Interface der Verkehr wohin geht. Beispiele: LAN → WAN WAN → DMZ DMZ → LAN VPN → Servernetz Gastnetz → Internet Managementnetz → Switches Viele Fehler entstehen, weil Regeln in der falschen Richtung erstellt werden. Merksatz: Firewall-Regeln sind richtungsabhängig. --- **Zone** Eine Zone ist ein Sicherheitsbereich. Beispiele: - LAN - WAN - DMZ - Gastnetz - Servernetz - Managementnetz - VPN - IoT-Netz Regeln werden häufig von Zone zu Zone definiert. Beispiel: LAN → WAN: HTTPS erlauben WAN → LAN: blockieren Merksatz: Zonen helfen, Netzbereiche mit unterschiedlichem Schutzbedarf zu trennen. --- **Interface** Ein Interface ist eine konkrete Netzwerkschnittstelle der Firewall. Beispiele: WAN-Port LAN-Port DMZ-Port VLAN-Interface VPN-Interface Manche Firewalls arbeiten stärker mit Interfaces, andere stärker mit Zonen. Merksatz: Interface = konkrete Schnittstelle, Zone = logischer Sicherheitsbereich. --- **Regelreihenfolge** Viele Firewalls prüfen Regeln von oben nach unten. Die erste passende Regel entscheidet. Beispiel: Regel 1: Blockiere LAN → Server TCP 443 Regel 2: Erlaube LAN → Server TCP 443 Ergebnis: Verkehr wird blockiert, weil Regel 1 zuerst passt. Merksatz: Die erste passende Regel gewinnt. --- **Spezifisch vor allgemein** Spezifische Regeln sollten vor allgemeinen Regeln stehen. Beispiel richtig: Regel 1: Erlaube Admin-PC → Server SSH Regel 2: Blockiere restliches SSH Beispiel falsch: Regel 1: Blockiere restliches SSH Regel 2: Erlaube Admin-PC → Server SSH Im falschen Beispiel wird die Erlaubnis nie erreicht. Merksatz: Spezifische Regeln vor allgemeine Regeln setzen. --- **Explizite Regeln** Explizite Regeln sind bewusst angelegte Regeln. Beispiel: Erlaube Webserver → Datenbank TCP 5432 Diese Regel beschreibt genau: wer wohin über welchen Dienst kommunizieren darf. Merksatz: Explizite Regeln sind gezielte Erlaubnisse oder Verbote. --- **Implizite Regel** Viele Firewalls haben am Ende eine implizite Regel. Diese lautet häufig sinngemäß: Alles blockieren, was nicht vorher erlaubt wurde. Das nennt man oft: implicit deny Diese Regel ist nicht immer sichtbar, wirkt aber trotzdem. Merksatz: Am Ende steht oft ein unsichtbares „alles blockieren“. --- **Default Deny** Default Deny bedeutet: Standardmäßig ist alles verboten, außer es wurde ausdrücklich erlaubt. Das ist sicherer, weil neue oder vergessene Dienste nicht automatisch erreichbar sind. Beispiel: LAN → WAN nur HTTP, HTTPS und DNS erlauben. Alles andere blockieren. Merksatz: Default Deny ist ein wichtiges Sicherheitsprinzip. --- **Default Allow** Default Allow bedeutet: Standardmäßig ist alles erlaubt, außer es wurde ausdrücklich blockiert. Das ist einfacher, aber riskanter. Problem: Unbekannte Dienste können unbeabsichtigt erreichbar sein. Merksatz: Default Allow ist bequem, aber oft unsicherer. --- **Allow-Regel** Eine Allow-Regel erlaubt bestimmten Verkehr. Beispiel: Erlaube Quelle: LAN Ziel: Internet Dienst: HTTPS TCP 443 Bedeutung: Clients im LAN dürfen HTTPS-Verbindungen ins Internet aufbauen. Merksatz: Allow-Regel öffnet gezielt Kommunikation. --- **Deny-Regel** Eine Deny-Regel blockiert bestimmten Verkehr. Beispiel: Blockiere Quelle: Gastnetz Ziel: LAN Dienst: any Bedeutung: Gäste dürfen nicht auf interne Systeme zugreifen. Merksatz: Deny-Regel verhindert bestimmte Kommunikation. --- **Drop-Regel** Drop bedeutet: Paket wird still verworfen. Der Absender bekommt keine direkte Antwort. Vorteil: weniger Informationen für Angreifer Nachteil: Fehlersuche kann schwieriger sein, weil Verbindungen einfach timeouten. Merksatz: Drop = still verwerfen. --- **Reject-Regel** Reject bedeutet: Paket wird aktiv abgelehnt. Der Absender erhält eine Rückmeldung. Vorteil: Fehlersuche oft klarer Nachteil: Absender erfährt, dass ein System oder Filter aktiv antwortet. Merksatz: Reject = aktiv ablehnen. --- **Logging bei Firewall-Regeln** Logging bedeutet: Treffer einer Regel werden protokolliert. Logs können zeigen: - Quelle - Ziel - Port - Protokoll - Zeit - Aktion - Regelname - Zone - Interface Logging ist wichtig für: - Fehlersuche - Sicherheitsanalyse - Nachvollziehbarkeit - Angriffserkennung Merksatz: Ohne Firewall-Logs ist Fehlersuche oft blind. --- **Nicht jede Regel sollte alles loggen** Zu viel Logging kann problematisch sein. Nachteile: - sehr große Logmengen - wichtige Ereignisse gehen unter - Speicherverbrauch - Performancebelastung - unübersichtliche Analyse Sinnvoll: wichtige erlaubte Zugriffe loggen wichtige Blockierungen loggen Standardrauschen begrenzen Merksatz: Logging gezielt einsetzen. --- **Objekte in Firewall-Regeln** Viele Firewalls nutzen Objekte. Beispiele: Hostobjekt: webserver01 = 192.168.20.10 Netzwerkobjekt: LAN = 192.168.10.0/24 Dienstobjekt: HTTPS = TCP 443 Vorteil: Regeln werden lesbarer und leichter pflegbar. Merksatz: Objekte machen Firewall-Regeln übersichtlicher. --- **Adressobjekte** Adressobjekte beschreiben IP-Adressen oder Netze. Beispiele: Admin-PC = 192.168.10.50 Webserver = 192.168.20.10 Servernetz = 192.168.20.0/24 Gastnetz = 192.168.50.0/24 Merksatz: Adressobjekte benennen IP-Adressen und Netze. --- **Dienstobjekte** Dienstobjekte beschreiben Ports und Protokolle. Beispiele: HTTPS = TCP 443 DNS = UDP/TCP 53 SSH = TCP 22 NTP = UDP 123 Merksatz: Dienstobjekte benennen Protokoll-Port-Kombinationen. --- **Gruppenobjekte** Objekte können zu Gruppen zusammengefasst werden. Beispiel: Webdienste: HTTP HTTPS Oder: Admin-Hosts: Admin-PC-1 Admin-PC-2 Bastion-Host Vorteil: weniger doppelte Regeln bessere Übersicht Merksatz: Gruppenobjekte vereinfachen Regelwerke. --- **Any** Any bedeutet: beliebig Beispiele: Quelle: any Ziel: any Dienst: any Any kann sinnvoll sein, ist aber gefährlich, wenn es zu großzügig verwendet wird. Besonders riskant: Quelle any Ziel any Dienst any Aktion allow Merksatz: Any sparsam verwenden. --- **Any-Any-Regel** Eine Any-Any-Regel erlaubt sehr viel. Beispiel: Quelle: any Ziel: any Dienst: any Aktion: allow Das ist meistens ein Sicherheitsproblem. Solche Regeln sollten vermieden, dokumentiert oder zeitlich begrenzt werden. Merksatz: Any-Any ist fast immer zu offen. --- **Temporäre Regeln** Temporäre Firewall-Regeln entstehen oft für Tests oder Störungen. Problem: Sie werden später vergessen. Deshalb sollten temporäre Regeln enthalten: - Zweck - Verantwortlicher - Ablaufdatum - Ticketnummer - Kommentar - Review-Datum Merksatz: Temporäre Regeln brauchen Ablaufdatum. --- **Kommentare in Firewall-Regeln** Kommentare helfen, den Zweck einer Regel zu verstehen. Ein guter Kommentar enthält: - Warum existiert die Regel? - Wer hat sie angefordert? - Welcher Dienst wird benötigt? - Gibt es ein Ticket? - Ist sie dauerhaft oder temporär? Schlecht: Test Besser: Ticket 1234: Webserver DMZ darf Datenbank TCP 5432 erreichen. Merksatz: Firewall-Regeln ohne Kommentar werden später unklar. --- **Regeln nach Diensten planen** Regeln sollten vom benötigten Dienst aus geplant werden. Beispiel: Anwendung braucht Datenbankzugriff. Dann fragt man: Welche Quelle? Welches Ziel? Welcher Port? Welches Protokoll? Welche Richtung? Dauerhaft oder temporär? Muss es geloggt werden? Merksatz: Erst Bedarf klären, dann Regel erstellen. --- **Regel zu breit** Eine zu breite Regel erlaubt mehr als nötig. Beispiel schlecht: LAN → Servernetz any erlauben Besser: Anwendungsserver → Datenbank TCP 5432 erlauben Warum? Wenn ein Client kompromittiert wird, kann er bei breiten Regeln mehr Ziele erreichen. Merksatz: Breite Regeln erhöhen die Angriffsfläche. --- **Regel zu eng** Eine zu enge oder falsche Regel kann Dienste stören. Beispiel: DNS nur UDP 53 erlaubt, aber TCP 53 wird für bestimmte Antworten benötigt. Oder: FTP-Port 21 erlaubt, aber passive Datenports fehlen. Merksatz: Regeln müssen sicher, aber technisch vollständig sein. --- **Rückverkehr** Bei Stateful Firewalls wird Rückverkehr oft automatisch erlaubt, wenn er zu einer bestehenden Verbindung gehört. Beispiel: Client → Webserver TCP 443 erlaubt Antwort: Webserver → Client gehört zur bestehenden Verbindung und wird erlaubt. Bei stateless Regeln muss Rückverkehr oft separat betrachtet werden. Merksatz: Stateful Firewalls erleichtern Rückverkehr. --- **Asymmetrischer Rückweg** Eine Stateful Firewall erwartet, dass Hin- und Rückverkehr über dieselbe Firewall laufen. Wenn der Rückweg anders läuft, kennt die Firewall die Verbindung nicht. Folge: Antwortverkehr kann blockiert werden. Merksatz: Stateful Firewalls brauchen passenden Hin- und Rückweg. --- **Regelrichtung bei Client-Server-Kommunikation** Bei Client-Server-Kommunikation startet meistens der Client die Verbindung. Beispiel: Client im LAN ruft Webserver in DMZ auf. Regel: Quelle: LAN-Client Ziel: DMZ-Webserver Dienst: HTTPS TCP 443 Nicht umgekehrt. Merksatz: Regelrichtung nach Verbindungsaufbau bestimmen. --- **Quellport und Zielport** Bei Client-Server-Verbindungen ist der Zielport meist der bekannte Dienstport. Beispiel: Client-Quellport: zufällig hoher Port Server-Zielport: TCP 443 Firewall-Regeln beziehen sich meist auf den Zielport des Dienstes. Merksatz: Standardport ist meistens Zielport beim Server. --- **Ephemeral Ports** Ephemeral Ports sind kurzlebige hohe Ports, die Clients für ausgehende Verbindungen verwenden. Beispiel: Client 192.168.10.50:53124 → Webserver 203.0.113.10:443 Der Quellport 53124 ist ein temporärer Clientport. Merksatz: Clients nutzen temporäre Quellports. --- **ICMP in Firewall-Regeln** ICMP ist wichtig für Diagnose und Netzwerkfunktion. Beispiele: - Ping - Ziel nicht erreichbar - Fragmentierung nötig - Time Exceeded bei Traceroute ICMP komplett zu blockieren kann Fehlersuche erschweren und bestimmte Netzwerkfunktionen stören. Merksatz: ICMP ist mehr als nur Ping. --- **Ping erlauben oder blockieren?** Ping kann bei Fehlersuche helfen. Aber: Ping offen zeigt, dass ein System erreichbar ist. In vielen Umgebungen wird Ping intern erlaubt, extern aber eingeschränkt. Wichtig ist eine bewusste Entscheidung. Merksatz: ICMP bewusst regeln, nicht blind alles blockieren. --- **DNS-Regeln** DNS braucht je nach Fall UDP und TCP 53. Typische Regel: Clients → interner DNS-Server UDP/TCP 53 erlauben Nicht ideal: Alle Clients → beliebige externe DNS-Server erlauben Warum? Interne DNS-Kontrolle, Filterung und Protokollierung können umgangen werden. Merksatz: DNS gezielt zu erlaubten Resolvern steuern. --- **HTTP- und HTTPS-Regeln** Typische ausgehende Webregel: Clients → Internet TCP 80 und TCP 443 erlauben Sicherer: über Proxy steuern oder Zielkategorien beschränken Wichtig: TCP 443 erlaubt nicht automatisch sichere Anwendung, weil auch unerwünschter Verkehr über 443 laufen kann. Merksatz: HTTPS-Port offen heißt nicht automatisch sicherer Inhalt. --- **Administrationsregeln** Administrative Zugriffe sollten besonders eingeschränkt werden. Beispiele: SSH nur aus Managementnetz RDP nur über VPN Firewall-Webinterface nur von Admin-PCs Datenbankport nicht für Clients öffnen Hypervisor-Management getrennt halten Merksatz: Adminzugriffe nur aus Managementbereichen erlauben. --- **Datenbankregeln** Datenbanken sollten nicht allgemein erreichbar sein. Beispiel: Webserver → Datenbank TCP 5432 erlauben Aber nicht: gesamtes LAN → Datenbank any erlauben Datenbankzugriff ist besonders sensibel. Merksatz: Datenbanken nur für notwendige Systeme öffnen. --- **DMZ-Regeln** In einer DMZ gilt: Internet → DMZ: nur öffentliche Dienste erlauben DMZ → LAN: nur zwingend notwendige Verbindungen erlauben LAN → DMZ: Administration nur gezielt erlauben Beispiel: Internet → Reverse Proxy TCP 443 erlauben Reverse Proxy → interner Webdienst TCP 8080 erlauben Reverse Proxy → gesamtes LAN any blockieren Merksatz: DMZ-Regeln müssen besonders eng sein. --- **Gastnetz-Regeln** Typische Gastnetzregeln: Gastnetz → Internet: HTTP/HTTPS/DNS erlauben Gastnetz → LAN: blockieren Gastnetz → Managementnetz: blockieren Gastnetz → Servernetz: blockieren Merksatz: Gäste bekommen Internet, aber keinen internen Zugriff. --- **IoT-Regeln** IoT-Geräte sollten eingeschränkt werden. Beispiele: IoT → Internet nur notwendige Dienste IoT → LAN blockieren Admin-Netz → IoT-Verwaltung erlauben IoT → DNS nur zu internem Resolver IoT → NTP nur zu freigegebenem Zeitserver Merksatz: IoT-Geräte nur kontrolliert kommunizieren lassen. --- **VPN-Regeln** VPN-Zugriff sollte nicht automatisch alles erlauben. Besser: VPN-Gruppe Support → bestimmte Server RDP VPN-Gruppe Admin → Managementnetz SSH VPN-Gruppe Extern → nur benötigte Anwendung Merksatz: VPN-Zugriff nach Rolle und Bedarf einschränken. --- **Regelprüfung bei Störung** Wenn ein Dienst nicht funktioniert, prüft man bei der Firewall: - kommt Verkehr an? - welche Regel greift? - wird erlaubt oder blockiert? - stimmt Quelle? - stimmt Ziel? - stimmt Port? - stimmt Protokoll? - stimmt Richtung? - greift vorher eine Blockregel? - ist NAT zusätzlich nötig? - gibt es Rückverkehr? Merksatz: Bei Störung immer die tatsächlich getroffene Regel prüfen. --- **Hit Count** Viele Firewalls zeigen, wie oft eine Regel getroffen wurde. Das nennt man oft: Hit Count Nützlich für: - aktive Regeln erkennen - ungenutzte Regeln finden - Regelprüfung - Aufräumen - Fehlersuche Aber: Kein Hit Count heißt nicht immer, dass Regel sicher gelöscht werden kann. Merksatz: Hit Count hilft, ersetzt aber keine fachliche Prüfung. --- **Shadowed Rule** Eine shadowed rule ist eine Regel, die nie erreicht wird, weil eine vorherige Regel den Verkehr bereits behandelt. Beispiel: Regel 1: Blockiere LAN → Server any Regel 2: Erlaube LAN → Server HTTPS Regel 2 wird nie wirken, wenn Regel 1 vorher greift. Merksatz: Shadowed Rule = Regel wird durch frühere Regel verdeckt. --- **Redundante Regel** Eine redundante Regel ist überflüssig, weil eine andere Regel denselben Verkehr bereits behandelt. Problem: Regelwerk wird unübersichtlich. Merksatz: Redundante Regeln erschweren Wartung und Fehlersuche. --- **Regelkonflikt** Ein Regelkonflikt entsteht, wenn Regeln widersprüchlich oder unklar wirken. Beispiel: Eine Regel erlaubt Zugriff. Eine andere blockiert scheinbar denselben Zugriff. Entscheidend ist dann: Reihenfolge Genauigkeit Zonen Objekte tatsächlicher Treffer Merksatz: Bei Konflikten zählt die Regel, die tatsächlich zuerst passt. --- **Firewall-Änderungsprozess** Firewall-Änderungen sollten kontrolliert ablaufen. Typischer Ablauf: 1. Anforderung stellen. 2. Zweck beschreiben. 3. Quelle, Ziel und Dienst angeben. 4. Risiko bewerten. 5. Änderung genehmigen. 6. Regel umsetzen. 7. Funktion testen. 8. Dokumentation aktualisieren. 9. Regel später überprüfen. Merksatz: Firewall-Änderungen brauchen Kontrolle und Dokumentation. --- **Vor einer Regeländerung klären** Vor einer Firewall-Regeländerung sollte klar sein: Wer braucht Zugriff? Von wo nach wo? Welcher Dienst? Welcher Port? TCP oder UDP? Dauerhaft oder temporär? Muss NAT eingerichtet werden? Gibt es Sicherheitsrisiken? Gibt es eine bessere Alternative? Wer ist verantwortlich? Merksatz: Keine Firewall-Regel ohne klaren Zweck. --- **Nach einer Regeländerung testen** Nach Änderung testet man: funktioniert der Dienst? ist nur gewünschter Zugriff möglich? sind unerwünschte Zugriffe blockiert? erscheinen Logs korrekt? greift die richtige Regel? ist NAT korrekt? funktioniert Rückverkehr? ist Dokumentation aktualisiert? Merksatz: Firewall-Regel nach Änderung immer testen. --- **Regelbereinigung** Regelwerke sollten regelmäßig bereinigt werden. Dabei prüft man: - alte Regeln - temporäre Regeln - ungenutzte Regeln - Any-Any-Regeln - redundante Regeln - shadowed rules - fehlende Kommentare - zu breite Freigaben - nicht mehr benötigte Dienste Merksatz: Firewall-Regelwerke altern und müssen gepflegt werden. --- **Typische Fehler bei Firewall-Regeln** Typische Fehler sind: - falsche Richtung - falsche Quelle - falsches Ziel - falscher Port - TCP statt UDP oder umgekehrt - falsche Zone - falsche Regelreihenfolge - NAT vergessen - Rückweg vergessen - DNS-Name zeigt auf anderes Ziel - Objekt falsch gepflegt - temporäre Regel vergessen - zu breite Any-Regel Merksatz: Firewall-Fehler sind oft Detailfehler. --- **Beispiel: Webserver in DMZ freigeben** Anforderung: Externe Benutzer sollen Webserver in DMZ per HTTPS erreichen. Benötigt: Quelle: Internet Ziel: Webserver oder Reverse Proxy in DMZ Dienst: HTTPS TCP 443 Richtung: WAN → DMZ NAT: öffentliche IP auf DMZ-Ziel weiterleiten Firewall: TCP 443 erlauben Merksatz: Externer Webdienst braucht NAT und passende Firewall-Regel. --- **Beispiel: Adminzugriff auf DMZ-Server** Anforderung: Administrator soll per SSH auf DMZ-Server zugreifen. Besser: Quelle: Admin-Netz oder Bastion Host Ziel: DMZ-Server Dienst: SSH TCP 22 Richtung: Management → DMZ Nicht gut: Internet → DMZ-Server SSH erlauben Merksatz: Administration nicht aus beliebigen Quellen erlauben. --- **Beispiel: Webserver zur Datenbank** Anforderung: Webserver braucht Datenbankzugriff. Regel: Quelle: Webserver Ziel: Datenbankserver Dienst: passender Datenbankport Richtung: DMZ oder App-Netz → DB-Netz Wichtig: Nicht gesamtes Netz zur Datenbank erlauben. Merksatz: Datenbankzugriff nur von notwendigen Systemen erlauben. --- **Beispiel: DNS im Clientnetz** Anforderung: Clients sollen Namen auflösen. Regel: Quelle: Clientnetz Ziel: interner DNS-Server Dienst: DNS UDP/TCP 53 Optional: externe DNS-Server für Clients blockieren, damit DNS zentral kontrolliert bleibt. Merksatz: Clients sollten definierte DNS-Resolver nutzen. --- **Beispiel: Gastnetz** Anforderung: Gäste brauchen Internet, aber keinen Zugriff ins LAN. Regeln: Gastnetz → Internet HTTPS erlauben Gastnetz → Internet DNS erlauben Gastnetz → LAN blockieren Gastnetz → Managementnetz blockieren Gastnetz → Servernetz blockieren Merksatz: Gastnetz strikt vom internen Netz trennen. --- **Was Firewall-Regelwerke nicht lösen** Firewall-Regeln lösen nicht automatisch: - falsche Anwendungskonfiguration - schwache Passwörter - fehlende Updates - unsichere Dienste - fehlerhafte DNS-Einträge - falsche Zertifikate - schlechte Berechtigungen - fehlendes Monitoring - fehlende Backups Merksatz: Firewall-Regeln sind wichtig, ersetzen aber kein Gesamtsicherheitskonzept. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Welche Bestandteile hat eine Firewall-Regel? - Warum ist die Regelreihenfolge wichtig? - Was bedeutet Default Deny? - Was ist der Unterschied zwischen Allow, Drop und Reject? - Warum sind Any-Any-Regeln gefährlich? - Warum sollten spezifische Regeln vor allgemeinen Regeln stehen? - Was ist eine implizite Deny-Regel? - Was ist ein Dienstobjekt? - Was ist ein Adressobjekt? - Was ist eine shadowed rule? - Warum müssen Firewall-Regeln dokumentiert werden? - Warum sind temporäre Regeln riskant? - Wie prüft man eine Firewall-Regel bei einer Störung? - Warum reicht eine NAT-Regel allein nicht aus? - Warum sollte VPN-Zugriff nicht automatisch alles erlauben? --- **Typische Prüfungsfallen** Firewall-Regeln sind richtungsabhängig. Die erste passende Regel entscheidet. Spezifisch vor allgemein. Port immer mit Protokoll betrachten. TCP 53 ist nicht UDP 53. TCP 443 ist nicht UDP 443. Any bedeutet beliebig. Any-Any ist meist zu offen. Default Deny ist sicherer als Default Allow. Drop und Reject sind nicht dasselbe. Logging ist wichtig, aber zu viel Logging kann unübersichtlich werden. NAT ersetzt keine Firewall-Regel. Firewall-Regel ersetzt keine NAT-Regel. Rückverkehr bei Stateful Firewalls beachten. Asymmetrisches Routing kann Stateful Firewalls stören. Temporäre Regeln brauchen Ablaufdatum. Regeln ohne Kommentar werden später problematisch. VPN-Zugriff muss ebenfalls eingeschränkt werden. DNS-Regeln sollten UDP und TCP beachten. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Firewall-Regel | Bedingung mit Aktion für Netzwerkverkehr | | Aktion | erlauben, blockieren, verwerfen oder ablehnen | | Quelle | System oder Netz, von dem Verkehr ausgeht | | Ziel | System oder Netz, das erreicht werden soll | | Dienst | Protokoll-Port-Kombination | | Richtung | Verkehrsrichtung zwischen Zonen oder Interfaces | | Zone | logischer Sicherheitsbereich | | Interface | konkrete Netzwerkschnittstelle | | Allow | Verkehr erlauben | | Deny | Verkehr blockieren | | Drop | Paket still verwerfen | | Reject | Paket aktiv ablehnen | | Default Deny | alles blockieren, außer erlaubt | | Any | beliebige Quelle, beliebiges Ziel oder beliebiger Dienst | | Any-Any | sehr breite Regel mit beliebig zu beliebig | | Hit Count | Anzahl der Regel-Treffer | | Shadowed Rule | verdeckte Regel, die nie erreicht wird | | Redundante Regel | überflüssige doppelte Regel | | Dienstobjekt | benannter Port mit Protokoll | | Adressobjekt | benannte IP-Adresse oder Netz | | Regelreview | regelmäßige Prüfung des Regelwerks | --- **IHK-sichere Kurzformulierung** Firewall-Regeln legen fest, welcher Netzwerkverkehr erlaubt oder blockiert wird. Eine Regel besteht typischerweise aus Aktion, Quelle, Ziel, Dienst, Protokoll, Port, Richtung und Zone. Viele Firewalls arbeiten Regeln von oben nach unten ab, sodass die erste passende Regel entscheidet. Deshalb müssen spezifische Regeln vor allgemeinen Regeln stehen. Das Prinzip Default Deny bedeutet, dass alles blockiert wird, was nicht ausdrücklich erlaubt wurde. Firewall-Regeln sollten möglichst eng gefasst, dokumentiert, regelmäßig überprüft und nach Änderungen getestet werden. NAT-Regeln und Firewall-Regeln sind zu unterscheiden: NAT übersetzt Adressen oder Ports, die Firewall erlaubt oder blockiert den Verkehr. --- **Merksätze** Firewall-Regel = Quelle, Ziel, Dienst und Aktion. Aktion entscheidet, was mit Verkehr passiert. Quelle = wer startet Verbindung. Ziel = wer soll erreicht werden. Dienst = Protokoll plus Port. Port immer mit TCP oder UDP betrachten. Richtung ist entscheidend. Zone = Sicherheitsbereich. Interface = konkrete Schnittstelle. Die erste passende Regel gewinnt. Spezifisch vor allgemein. Default Deny ist sicherer. Allow erlaubt. Deny blockiert. Drop schweigt. Reject antwortet. Any sparsam verwenden. Any-Any vermeiden. NAT ersetzt keine Firewall-Regel. Firewall-Regel ersetzt keine NAT-Regel. Stateful Firewall kennt Rückverkehr. Asymmetrischer Rückweg kann stören. DNS braucht oft UDP und TCP 53. Adminzugriffe nur aus Managementnetzen erlauben. Datenbanken nur für notwendige Systeme öffnen. VPN-Zugriff nicht automatisch alles erlauben. Temporäre Regeln brauchen Ablaufdatum. Kommentare erklären den Zweck. Hit Count hilft beim Prüfen. Shadowed Rules finden und bereinigen. Firewall-Regeln regelmäßig überprüfen.