# 11. Firewalls, NAT und DMZ # 11.1 Firewalls, NAT und DMZ Firewalls, NAT und DMZ gehören zu den wichtigsten Themen der Netzwerksicherheit. Sie werden verwendet, um Netzwerke zu schützen, Zugriffe zu steuern und interne Systeme vom Internet zu trennen. Wichtige Begriffe: - Firewall - Paketfilter - Stateful Inspection - Firewall-Regel - Allow - Deny - NAT - PAT - Portweiterleitung - DMZ - interne Zone - externe Zone - Sicherheitszone Merksatz: Firewall kontrolliert Zugriffe. NAT übersetzt Adressen. DMZ trennt öffentliche Dienste vom internen Netz. --- **Grundidee einer Firewall** Eine Firewall kontrolliert Netzwerkverkehr. Sie entscheidet: Darf dieser Datenverkehr durch? Oder wird er blockiert? Dabei prüft sie je nach Art und Konfiguration zum Beispiel: - Quell-IP-Adresse - Ziel-IP-Adresse - Protokoll - Quellport - Zielport - Verbindungsstatus - Richtung - Benutzer - Anwendung - Sicherheitszone Merksatz: Firewall = kontrollierter Übergang zwischen Netzen. --- **Warum braucht man Firewalls?** Ohne Firewall könnten Systeme oft zu viele Verbindungen annehmen. Eine Firewall reduziert die Angriffsfläche. Sie schützt vor: - unerwünschten Zugriffen - offenen Diensten - unkontrolliertem Datenverkehr - Angriffen aus fremden Netzen - ungewollter Kommunikation zwischen Netzbereichen - direktem Zugriff auf interne Systeme Merksatz: Firewall-Regeln begrenzen, wer mit wem sprechen darf. --- **Firewall ist nicht gleich Virenschutz** Eine Firewall kontrolliert Netzwerkverkehr. Ein Virenschutz prüft Dateien, Programme oder Verhalten auf Schadsoftware. Unterschied: | Schutz | Hauptaufgabe | |---|---| | Firewall | Netzwerkverkehr erlauben oder blockieren | | Virenschutz | Schadsoftware erkennen und blockieren | | EDR | Verhalten auf Endgeräten überwachen | | IDS/IPS | Angriffe im Netzwerk erkennen oder blockieren | Merksatz: Firewall schützt Netzwerkzugriffe, ersetzt aber keinen Virenschutz. --- **Firewall im OSI-Modell** Firewalls können auf verschiedenen Schichten arbeiten. | Firewall-Art | typische Schicht | Prüft vor allem | |---|---:|---| | Paketfilter | 3 / 4 | IP-Adressen, Protokoll, Ports | | Stateful Firewall | 3 / 4 | Verbindungsstatus zusätzlich | | Application Firewall | 7 | Anwendungsdaten und Protokolle | | Web Application Firewall | 7 | HTTP/HTTPS-Anfragen | Merksatz: Firewalls können je nach Art auf mehreren Schichten arbeiten. --- **Paketfilter** Ein Paketfilter entscheidet anhand einzelner Pakete. Typische Kriterien: - Quell-IP - Ziel-IP - Protokoll - Quellport - Zielport - Richtung - Interface Beispiel: Erlaube TCP von 192.168.10.0/24 nach 10.0.0.5 auf Port 443. Merksatz: Paketfilter prüft IP-Adressen und Ports. --- **Stateful Firewall** Eine Stateful Firewall merkt sich den Zustand von Verbindungen. Sie erkennt: Gehört dieses Paket zu einer bestehenden Verbindung? Beispiel: Client aus internem Netz baut HTTPS-Verbindung nach außen auf. Antwortpakete vom Webserver werden erlaubt, weil sie zu dieser bestehenden Verbindung gehören. Vorteil: Rückverkehr muss nicht immer als komplett neue Verbindung erlaubt werden. Merksatz: Stateful Firewall kennt bestehende Verbindungen. --- **Stateful Inspection** Stateful Inspection bedeutet: Die Firewall prüft den Verbindungszustand. Sie unterscheidet zum Beispiel: neue Verbindung bestehende Verbindung zugehörige Antwort ungültiges Paket Das ist besonders wichtig bei TCP. Merksatz: Stateful Inspection prüft, ob Verkehr zu einer erlaubten Verbindung gehört. --- **Stateless Firewall** Eine Stateless Firewall merkt sich keine Verbindungen. Sie betrachtet Pakete einzeln. Nachteil: Rückverkehr muss oft explizit geregelt werden. Vorteil: einfacher, schneller, aber weniger intelligent. Merksatz: Stateless = jedes Paket einzeln betrachten. --- **Firewall-Regel** Eine Firewall-Regel beschreibt, welcher Verkehr erlaubt oder blockiert wird. Typische Bestandteile: - Aktion - Quelle - Ziel - Dienst oder Port - Protokoll - Richtung - Interface oder Zone - Kommentar oder Beschreibung Beispiel: Erlaube Quelle: Internes Netz Ziel: Webserver in DMZ Dienst: HTTPS TCP 443 Merksatz: Firewall-Regel = Bedingung plus Aktion. --- **Allow und Deny** Firewall-Regeln haben meist eine Aktion. Wichtige Aktionen: Allow Deny Drop Reject Allow bedeutet: Verkehr erlauben. Deny, Drop oder Reject bedeuten: Verkehr blockieren. Merksatz: Allow erlaubt. Deny blockiert. --- **Drop und Reject unterscheiden** Drop bedeutet: Paket wird verworfen, ohne Antwort. Reject bedeutet: Paket wird abgelehnt, mit Antwort an den Absender. Unterschied: | Aktion | Verhalten | |---|---| | Drop | still verwerfen | | Reject | aktiv ablehnen | | Allow | erlauben | Merksatz: Drop schweigt. Reject antwortet. --- **Default Deny** Default Deny bedeutet: Alles ist verboten, was nicht ausdrücklich erlaubt ist. Das ist ein wichtiges Sicherheitsprinzip. Beispiel: Alle Verbindungen blockieren. Nur notwendige Dienste erlauben. Vorteil: unbekannter oder unnötiger Verkehr wird nicht automatisch erlaubt. Merksatz: Erst alles verbieten, dann gezielt erlauben. --- **Default Allow** Default Allow bedeutet: Alles ist erlaubt, was nicht ausdrücklich verboten ist. Das ist oft riskanter, weil neue oder vergessene Dienste automatisch erreichbar sein können. Merksatz: Default Allow ist bequem, aber oft unsicherer. --- **Regelreihenfolge** Viele Firewalls arbeiten Regeln von oben nach unten ab. Die erste passende Regel entscheidet. Beispiel: Regel 1: Blockiere Ziel TCP 443 Regel 2: Erlaube Ziel TCP 443 Ergebnis: Wenn Regel 1 zuerst passt, wird blockiert. Merksatz: Reihenfolge der Firewall-Regeln ist entscheidend. --- **Spezifische Regeln vor allgemeinen Regeln** Spezifische Regeln sollten vor allgemeinen Regeln stehen. Beispiel: Erlaube Admin-PC zu Server auf SSH. Danach: Blockiere restliches SSH. Wenn die allgemeine Blockregel zuerst steht, kommt die spezifische Erlaubnis nie zum Tragen. Merksatz: Spezifisch vor allgemein. --- **Firewall-Zonen** Viele Firewalls arbeiten mit Zonen. Typische Zonen: - LAN - WAN - DMZ - Gastnetz - Servernetz - Managementnetz - VPN - IoT-Netz Zonen helfen, Netzbereiche logisch zu trennen. Merksatz: Zone = Sicherheitsbereich im Netzwerk. --- **LAN und WAN** LAN steht für: Local Area Network WAN steht für: Wide Area Network Vereinfacht: LAN = internes Netz WAN = externes Netz oder Internetseite Merksatz: LAN innen, WAN außen. --- **Interne Zone** Die interne Zone enthält normalerweise vertrauenswürdigere Systeme. Beispiele: - Clients - interne Server - Drucker - Verwaltungsgeräte - interne Anwendungen Trotzdem gilt: Auch intern sollte nicht alles blind erlaubt sein. Merksatz: Intern ist nicht automatisch sicher. --- **Externe Zone** Die externe Zone ist meist das Internet oder ein fremdes Netz. Von dort kommen potenziell untrusted Verbindungen. Deshalb werden eingehende Verbindungen besonders streng kontrolliert. Merksatz: Extern = nicht vertrauenswürdig. --- **DMZ** DMZ steht für: Demilitarized Zone Eine DMZ ist ein separates Netz, in dem Dienste stehen, die von außen erreichbar sein müssen. Beispiele: - Webserver - Reverse Proxy - Mailgateway - VPN-Gateway - öffentliche API - DNS-Server für externe Anfragen Merksatz: DMZ = eigenes Netz für öffentlich erreichbare Dienste. --- **Warum gibt es eine DMZ?** Eine DMZ schützt das interne Netz. Idee: Öffentliche Dienste sollen nicht direkt im internen LAN stehen. Wenn ein Server in der DMZ kompromittiert wird, soll der Angreifer nicht automatisch Zugriff auf das interne Netz erhalten. Merksatz: DMZ begrenzt Schaden bei öffentlichen Diensten. --- **DMZ-Grundaufbau** Typischer Aufbau: Internet → Firewall → DMZ → Firewall-Regeln → internes LAN Oder mit drei Zonen: WAN DMZ LAN Regeln werden gezielt zwischen diesen Zonen erstellt. Merksatz: DMZ liegt kontrolliert zwischen Internet und internem Netz. --- **Regeln für eine DMZ** Typische Regelidee: Internet darf nur bestimmte Dienste in der DMZ erreichen. Beispiel: Internet → DMZ-Webserver: TCP 443 erlaubt Internet → internes LAN: blockiert DMZ → internes LAN: nur notwendige Verbindungen erlaubt internes LAN → DMZ: Administration nur von Admin-Systemen Merksatz: DMZ darf nicht freie Brücke ins LAN sein. --- **DMZ und internes Netz** Ein häufiger Fehler ist: DMZ-Server dürfen alles im internen Netz erreichen. Das ist gefährlich. Besser: Nur notwendige Verbindungen erlauben. Beispiel: Webserver in DMZ darf nur zur Datenbank auf TCP 5432. Oder: Reverse Proxy in DMZ darf nur zu bestimmten internen Webdiensten. Merksatz: Von DMZ ins LAN nur gezielt erlauben. --- **DMZ und Administration** Administrationszugriff auf DMZ-Systeme sollte eingeschränkt sein. Beispiele: Admin-Netz → DMZ-Server SSH erlauben normale Clients → DMZ-Server SSH blockieren Internet → DMZ-Server SSH blockieren Sinnvoll: Administration über VPN, Managementnetz oder Bastion Host. Merksatz: DMZ-Administration nur kontrolliert erlauben. --- **Bastion Host** Ein Bastion Host ist ein besonders abgesicherter Sprungserver. Er wird genutzt, um administrative Zugriffe zu bündeln. Beispiel: Admin verbindet sich zum Bastion Host. Von dort aus erfolgt Zugriff auf Server in der DMZ. Vorteile: - zentrale Kontrolle - Protokollierung - weniger direkte Zugriffe - bessere Absicherung Merksatz: Bastion Host = abgesicherter Zugangspunkt für Administration. --- **NAT** NAT steht für: Network Address Translation NAT übersetzt IP-Adressen. Typische Nutzung: private interne IP-Adressen werden beim Zugriff ins Internet in eine öffentliche IP-Adresse übersetzt. Beispiel: intern: 192.168.10.50 extern sichtbar: öffentliche Router-IP Merksatz: NAT übersetzt IP-Adressen. --- **Warum braucht man NAT?** IPv4-Adressen sind knapp. Private IPv4-Adressen werden intern verwendet und sind im Internet nicht direkt geroutet. NAT ermöglicht, dass viele interne Geräte über eine oder wenige öffentliche IPv4-Adressen ins Internet gehen. Merksatz: NAT spart öffentliche IPv4-Adressen. --- **Private IPv4-Adressbereiche** Private IPv4-Adressbereiche sind: | Bereich | CIDR | |---|---| | 10.0.0.0 bis 10.255.255.255 | 10.0.0.0/8 | | 172.16.0.0 bis 172.31.255.255 | 172.16.0.0/12 | | 192.168.0.0 bis 192.168.255.255 | 192.168.0.0/16 | Diese Adressen werden im Internet nicht direkt geroutet. Merksatz: Private IPv4-Adressen sind für interne Netze gedacht. --- **Öffentliche IP-Adresse** Eine öffentliche IP-Adresse ist im Internet routbar. Sie wird zum Beispiel vom Provider vergeben. Beispiel: Router hat öffentliche IP-Adresse am WAN. Interne Clients verwenden private Adressen und werden per NAT nach außen übersetzt. Merksatz: Öffentliche IP ist im Internet erreichbar, private IP normalerweise nicht. --- **Source NAT** Source NAT ändert die Quelladresse eines Pakets. Typischer Fall: interner Client geht ins Internet. Vor NAT: Quelle: 192.168.10.50 Ziel: 93.184.216.34 Nach NAT: Quelle: öffentliche Router-IP Ziel: 93.184.216.34 Merksatz: Source NAT ändert die Quelle. --- **Destination NAT** Destination NAT ändert die Zieladresse eines Pakets. Typischer Fall: Portweiterleitung von außen nach innen. Vor NAT: Ziel: öffentliche IP TCP 443 Nach NAT: Ziel: interner Webserver 192.168.10.20 TCP 443 Merksatz: Destination NAT ändert das Ziel. --- **PAT** PAT steht für: Port Address Translation PAT übersetzt zusätzlich Ports. Dadurch können viele interne Clients gleichzeitig eine öffentliche IP-Adresse nutzen. Beispiel: Client A intern: 192.168.10.10:50001 Client B intern: 192.168.10.11:50002 Extern sichtbar über dieselbe öffentliche IP, aber mit unterschiedlichen Ports. Merksatz: PAT = viele interne Geräte über eine öffentliche IP mit Portübersetzung. --- **NAT und PAT unterscheiden** | Begriff | Bedeutung | |---|---| | NAT | Übersetzung von IP-Adressen | | PAT | Übersetzung von IP-Adressen und Ports | | Source NAT | Quelladresse wird geändert | | Destination NAT | Zieladresse wird geändert | | Portweiterleitung | eingehender Port wird intern weitergeleitet | Merksatz: NAT übersetzt Adressen. PAT übersetzt zusätzlich Ports. --- **Portweiterleitung** Portweiterleitung bedeutet: Eine Verbindung von außen auf einen bestimmten Port wird an ein internes Ziel weitergeleitet. Beispiel: öffentliche IP TCP 443 → interner Server 192.168.10.20 TCP 443 Typische Nutzung: - Webserver - Reverse Proxy - VPN-Gateway - Mailserver - Spielserver - Testsysteme Merksatz: Portweiterleitung macht internen Dienst von außen erreichbar. --- **Portweiterleitung und Sicherheit** Portweiterleitung erhöht die Angriffsfläche. Warum? Ein interner Dienst wird von außen erreichbar. Deshalb wichtig: - nur notwendige Ports öffnen - Dienste aktuell halten - starke Authentifizierung - TLS verwenden - Logs prüfen - Zugriff einschränken - nach Möglichkeit DMZ nutzen - keine Admin-Dienste offen ins Internet Merksatz: Jeder geöffnete Port ist ein potenzielles Risiko. --- **Firewall-Regel und NAT-Regel unterscheiden** Eine NAT-Regel übersetzt Adressen oder Ports. Eine Firewall-Regel erlaubt oder blockiert Verkehr. Beides ist nicht dasselbe. Beispiel: NAT-Regel: öffentliche IP TCP 443 → interner Webserver TCP 443 Firewall-Regel: Erlaube Internet → Webserver TCP 443 Wenn NAT gesetzt ist, aber Firewall blockiert, funktioniert der Zugriff trotzdem nicht. Merksatz: NAT leitet um. Firewall erlaubt oder blockiert. --- **Inbound und Outbound** Inbound bedeutet: eingehender Verkehr in Richtung eines Netzes oder Systems. Outbound bedeutet: ausgehender Verkehr aus einem Netz oder System. Beispiel: Client im LAN ruft Webseite im Internet auf: outbound aus LAN Internet greift auf Webserver in DMZ zu: inbound zur DMZ Merksatz: Inbound hinein, outbound hinaus. --- **East-West und North-South Traffic** North-South Traffic bedeutet: Verkehr zwischen internem Netz und externen Netzen. Beispiel: Client ins Internet East-West Traffic bedeutet: Verkehr innerhalb eines Rechenzentrums oder interner Netze. Beispiel: Webserver spricht mit Datenbankserver. Merksatz: North-South = nach außen oder innen. East-West = intern zwischen Systemen. --- **Firewall und Routing** Firewall und Routing sind nicht dasselbe. Routing entscheidet: Wohin wird ein Paket weitergeleitet? Firewall entscheidet: Darf das Paket weiter? Beides muss passen. Beispiel: Route vorhanden, aber Firewall blockiert: Verbindung geht nicht. Firewall erlaubt, aber Route fehlt: Verbindung geht nicht. Merksatz: Routing findet Weg. Firewall erlaubt Weg. --- **Firewall und DNS** DNS-Probleme können wie Firewall-Probleme aussehen. Beispiel: Benutzer ruft service.firma.de auf. DNS zeigt auf falsche IP. Dann erreicht der Client vielleicht den falschen Server oder bekommt gar keine Verbindung. Merksatz: Vor Firewall-Fehlersuche auch DNS prüfen. --- **Firewall und TLS** Eine Firewall kann TCP 443 erlauben, aber HTTPS kann trotzdem fehlschlagen. Mögliche Ursachen: - Zertifikat ungültig - falscher Hostname - falsches Backend - Reverse Proxy falsch - TLS-Version inkompatibel - Anwendung antwortet falsch Merksatz: Port 443 offen heißt nicht: HTTPS funktioniert korrekt. --- **Firewall und Protokolle** Ein Port allein beschreibt nicht immer alles. Beispiele: DNS nutzt UDP und TCP 53. FTP nutzt Steuer- und Datenverbindungen. SIP oder VoIP können zusätzliche Ports nutzen. HTTP/3 nutzt UDP 443. VPN-Protokolle nutzen unterschiedliche Ports und Protokolle. Merksatz: Immer Protokoll, Port und Verbindungsverhalten beachten. --- **Firewall-Logs** Firewall-Logs sind wichtig für Fehlersuche und Sicherheit. Sie zeigen zum Beispiel: - erlaubte Verbindungen - blockierte Verbindungen - Quell-IP - Ziel-IP - Port - Protokoll - Regelname - Zeitstempel - Interface oder Zone Merksatz: Firewall-Logs zeigen, ob Verkehr erlaubt oder blockiert wurde. --- **Typische Firewall-Fehler** Typische Fehler sind: - falsche Regelreihenfolge - falsche Quelle - falsches Ziel - falscher Port - falsches Protokoll - Regel in falscher Richtung - falsche Zone - NAT fehlt - Rückweg fehlt - DNS zeigt auf falsches Ziel - Dienst läuft nicht - asymmetrisches Routing Merksatz: Firewall-Fehler sind oft Regel-, Richtungs- oder Zonenfehler. --- **Fehlerbild: Dienst von außen nicht erreichbar** Mögliche Ursachen: - Portweiterleitung fehlt - Firewall-Regel fehlt - falscher Zielserver - falscher Zielport - Dienst läuft nicht - öffentliche IP falsch - DNS zeigt falsch - Provider blockiert Port - CGNAT - Reverse Proxy falsch - Zertifikat fehlerhaft Merksatz: Externer Zugriff braucht DNS, NAT, Firewall, Dienst und Rückweg. --- **Fehlerbild: Intern funktioniert, extern nicht** Mögliche Ursachen: - externe Firewall blockiert - NAT oder Portweiterleitung fehlt - externer DNS-Eintrag falsch - öffentliche IP falsch - CGNAT - Zertifikat nur intern passend - Dienst nur auf interner Adresse gebunden - Reverse Proxy nur intern konfiguriert Merksatz: Intern und extern getrennt prüfen. --- **Fehlerbild: Extern funktioniert, intern nicht** Mögliche Ursachen: - internes DNS zeigt falsch - Split DNS fehlt - Hairpin NAT fehlt - interne Firewall blockiert - interne Route fehlt - Zertifikatname passt intern nicht - Proxy- oder Gatewayproblem Merksatz: Extern erreichbar heißt nicht automatisch intern erreichbar. --- **Hairpin NAT** Hairpin NAT wird gebraucht, wenn interne Clients über die öffentliche Adresse auf einen internen Dienst zugreifen sollen. Beispiel: interner Client ruft öffentliche Domain auf. DNS liefert öffentliche IP. Router muss Verbindung wieder nach innen leiten. Wenn Hairpin NAT fehlt, funktioniert der Dienst extern, aber intern über den öffentlichen Namen nicht. Merksatz: Hairpin NAT ermöglicht internen Zugriff über öffentliche Adresse. --- **Split DNS als Alternative** Split DNS kann Hairpin NAT vermeiden. Dabei liefert DNS intern und extern unterschiedliche Antworten. Beispiel: service.firma.de extern: öffentliche IP service.firma.de intern: interne IP Vorteil: interne Clients gehen direkt zur internen Adresse. Merksatz: Split DNS liefert intern passende interne Adressen. --- **CGNAT** CGNAT steht für: Carrier Grade NAT Dabei hat der Anschluss keine eigene echte öffentliche IPv4-Adresse. Der Provider nutzt NAT für viele Kunden. Folge: eingehende Portweiterleitungen funktionieren oft nicht direkt. Mögliche Lösungen: - echte öffentliche IPv4 buchen - IPv6 nutzen - VPN-Tunnel - Cloud-Tunnel - Reverse Proxy über externen Server Merksatz: CGNAT verhindert oft direkte eingehende IPv4-Verbindungen. --- **Asymmetrisches Routing** Asymmetrisches Routing bedeutet: Hinweg und Rückweg laufen über unterschiedliche Wege. Das kann Firewalls stören, weil eine Stateful Firewall den Verbindungszustand auf einem Weg sieht, aber die Antwort über einen anderen Weg zurückkommt. Folge: Verbindung wird möglicherweise blockiert. Merksatz: Stateful Firewalls brauchen passenden Hin- und Rückweg. --- **Any-Any-Regel** Eine Any-Any-Regel erlaubt sehr viel. Beispiel: Quelle: any Ziel: any Dienst: any Aktion: allow Das ist gefährlich, weil fast jeder Verkehr erlaubt wird. Any-Any-Regeln sollten vermieden oder sehr gut begründet werden. Merksatz: Any-Any ist bequem, aber riskant. --- **Least Privilege bei Firewall-Regeln** Auch bei Firewall-Regeln gilt: nur erlauben, was wirklich benötigt wird. Beispiel schlecht: Erlaube gesamtes LAN zur DMZ auf alle Ports. Besser: Erlaube Admin-PC zur DMZ auf TCP 22. Erlaube Webserver zur Datenbank auf TCP 5432. Merksatz: Firewall-Regeln so eng wie möglich setzen. --- **Dokumentation von Firewall-Regeln** Firewall-Regeln sollten dokumentiert werden. Wichtige Angaben: - Zweck - Quelle - Ziel - Dienst - Verantwortlicher - Erstellungsdatum - Ablaufdatum bei temporären Regeln - Ticket oder Änderungsgrund - Risiko - Kommentar Merksatz: Undokumentierte Firewall-Regeln werden schnell zum Sicherheitsproblem. --- **Temporäre Firewall-Regeln** Temporäre Regeln sollten ein Ablaufdatum haben. Problem: Testregel wird erstellt. Niemand entfernt sie. Dienst bleibt unnötig offen. Besser: temporäre Regel mit Ablaufdatum, Kommentar und Review. Merksatz: Temporär darf nicht dauerhaft vergessen werden. --- **Firewall-Review** Firewall-Regeln sollten regelmäßig überprüft werden. Ziel: - alte Regeln entfernen - unnötige Freigaben schließen - Any-Any-Regeln vermeiden - Dokumentation aktualisieren - Sicherheitsrisiken reduzieren - Regelreihenfolge prüfen Merksatz: Firewall-Regeln brauchen regelmäßige Pflege. --- **Typische Sicherheitszonen** | Zone | Zweck | |---|---| | WAN | externes Netz / Internet | | LAN | internes Clientnetz | | DMZ | öffentlich erreichbare Dienste | | Servernetz | interne Server | | Managementnetz | Administration | | Gastnetz | Gäste ohne Zugriff auf intern | | IoT-Netz | Geräte mit eingeschränktem Vertrauen | | VPN-Zone | entfernte Benutzer nach VPN-Einwahl | Merksatz: Zonen trennen Systeme nach Schutzbedarf. --- **Gastnetz** Ein Gastnetz ist ein separates Netz für Besucher oder private Geräte. Ziel: Internetzugang ermöglichen, aber internes Netz schützen. Typische Regeln: Gastnetz → Internet erlaubt Gastnetz → internes LAN blockiert Gastnetz → Managementnetz blockiert Merksatz: Gastnetz darf nicht ins interne Netz führen. --- **Managementnetz** Ein Managementnetz dient zur Administration von Systemen. Dort können liegen: - Switch-Management - Firewall-Management - Server-Management - Hypervisor-Management - Storage-Management - IPMI / iLO / iDRAC Dieses Netz sollte besonders geschützt sein. Merksatz: Managementzugänge besonders abschotten. --- **IoT-Netz** Ein IoT-Netz trennt Geräte mit höherem Risiko vom restlichen Netz. Beispiele: - Kameras - smarte Sensoren - Türsysteme - Mediengeräte - Smart-Home-Geräte - Drucker je nach Umgebung Regelidee: IoT darf nur notwendige Ziele erreichen. Merksatz: IoT-Geräte nicht blind ins Hauptnetz lassen. --- **Firewall und VPN** VPN-Zugänge sollten in Firewall-Regeln berücksichtigt werden. Beispiel: VPN-Benutzer dürfen nur bestimmte interne Dienste erreichen. Nicht automatisch: VPN darf alles im LAN. Besser: VPN-Zone mit gezielten Regeln. Merksatz: VPN-Zugriff ebenfalls nach Least Privilege regeln. --- **Firewall und Monitoring** Firewalls sollten überwacht werden. Wichtige Punkte: - CPU und RAM - Verbindungsanzahl - blockierte Angriffe - VPN-Verbindungen - Regel-Treffer - ungewöhnlicher Traffic - Interface-Auslastung - Lizenzstatus - Updates - Log-Speicher Merksatz: Firewall ist kritische Infrastruktur und muss überwacht werden. --- **Firewall-Fehlersuche systematisch** Eine sinnvolle Reihenfolge: 1. Quelle bestimmen. 2. Ziel bestimmen. 3. Protokoll bestimmen. 4. Port bestimmen. 5. Richtung bestimmen. 6. Zone oder Interface bestimmen. 7. DNS-Auflösung prüfen. 8. Routing prüfen. 9. NAT-Regeln prüfen. 10. Firewall-Regeln prüfen. 11. Logs prüfen. 12. Dienst auf Zielsystem prüfen. 13. Rückweg prüfen. Merksatz: Quelle, Ziel, Port, Richtung und Logs sind entscheidend. --- **Was Firewalls nicht machen** Firewalls machen nicht automatisch: - Anwendungen fehlerfrei - Benutzer sicher - Passwörter stark - Systeme gepatcht - Malware unmöglich - Daten verschlüsselt - Berechtigungen korrekt - Backups vorhanden - Logs automatisch ausgewertet Merksatz: Firewall ist wichtig, aber nur ein Teil des Sicherheitskonzepts. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was macht eine Firewall? - Was ist der Unterschied zwischen Firewall und NAT? - Was bedeutet Stateful Inspection? - Was ist eine DMZ? - Warum stellt man öffentliche Server in eine DMZ? - Was ist NAT? - Was ist PAT? - Was ist eine Portweiterleitung? - Was ist der Unterschied zwischen Source NAT und Destination NAT? - Warum ist Default Deny sicherer? - Warum ist die Regelreihenfolge wichtig? - Warum sollte man Any-Any-Regeln vermeiden? - Warum funktioniert ein Dienst trotz NAT-Regel nicht? - Was ist der Unterschied zwischen Routing und Firewall? - Warum können interne und externe Zugriffe unterschiedlich funktionieren? - Was ist Hairpin NAT? - Was ist Split DNS? - Was bedeutet CGNAT? --- **Typische Prüfungsfallen** Firewall ist nicht NAT. NAT ist nicht automatisch Firewall. NAT übersetzt Adressen. Firewall erlaubt oder blockiert Verkehr. PAT übersetzt zusätzlich Ports. Portweiterleitung macht interne Dienste von außen erreichbar. NAT-Regel allein reicht nicht, wenn Firewall blockiert. Firewall-Regeln haben eine Richtung. Regelreihenfolge ist wichtig. Spezifische Regeln vor allgemeine Regeln. Default Deny ist sicherer als Default Allow. Any-Any-Regeln vermeiden. DMZ ist nicht das interne LAN. DMZ-Server dürfen nicht automatisch alles im LAN erreichen. Öffentliche Dienste gehören besser in die DMZ. Routing entscheidet den Weg. Firewall entscheidet die Erlaubnis. Port 443 offen heißt nicht, dass HTTPS korrekt funktioniert. CGNAT kann eingehende Portweiterleitungen verhindern. Hairpin NAT betrifft internen Zugriff über öffentliche Adresse. Split DNS kann Hairpin NAT vermeiden. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Firewall | kontrolliert Netzwerkverkehr | | Paketfilter | prüft IP-Adressen, Ports und Protokolle | | Stateful Firewall | merkt sich Verbindungszustände | | Stateful Inspection | Prüfung, ob Verkehr zu bestehender Verbindung gehört | | Regel | Bedingung mit Aktion | | Allow | erlauben | | Deny | blockieren | | Drop | still verwerfen | | Reject | aktiv ablehnen | | Default Deny | alles blockieren außer ausdrücklich erlaubt | | Zone | Sicherheitsbereich im Netzwerk | | DMZ | separates Netz für öffentliche Dienste | | NAT | Übersetzung von IP-Adressen | | PAT | Übersetzung von IP-Adressen und Ports | | Source NAT | Quelladresse wird geändert | | Destination NAT | Zieladresse wird geändert | | Portweiterleitung | externer Port wird intern weitergeleitet | | Hairpin NAT | interner Zugriff über öffentliche Adresse | | Split DNS | intern und extern unterschiedliche DNS-Antworten | | CGNAT | Provider-NAT für mehrere Kunden | | Any-Any | sehr weit gefasste Regel | | Bastion Host | abgesicherter Sprungserver | | Managementnetz | Netz für Administration | --- **IHK-sichere Kurzformulierung** Eine Firewall kontrolliert Netzwerkverkehr zwischen Systemen oder Netzbereichen und entscheidet anhand von Regeln, ob Verbindungen erlaubt oder blockiert werden. Typische Kriterien sind Quelle, Ziel, Protokoll, Port, Richtung und Zone. Eine Stateful Firewall berücksichtigt zusätzlich den Zustand bestehender Verbindungen. NAT übersetzt IP-Adressen, während PAT zusätzlich Ports übersetzt. Eine Portweiterleitung ist eine Form von Destination NAT, bei der ein externer Port an ein internes Ziel weitergeleitet wird. Eine DMZ ist ein separates Netz für Dienste, die von außen erreichbar sein müssen, damit diese nicht direkt im internen LAN stehen. Firewall, NAT, Routing und DNS müssen gemeinsam korrekt konfiguriert sein, damit ein Dienst erreichbar ist. --- **Merksätze** Firewall kontrolliert Verkehr. NAT übersetzt Adressen. PAT übersetzt Adressen und Ports. Firewall ist nicht NAT. NAT ist nicht automatisch Firewall. Routing findet den Weg. Firewall erlaubt den Weg. Default Deny ist sicherer. Regelreihenfolge ist wichtig. Spezifisch vor allgemein. Any-Any vermeiden. Drop schweigt. Reject antwortet. Stateful Firewall kennt Verbindungen. DMZ = separates Netz für öffentliche Dienste. DMZ schützt internes LAN. DMZ darf keine freie Brücke ins LAN sein. Portweiterleitung macht internen Dienst extern erreichbar. NAT-Regel plus Firewall-Regel müssen passen. Source NAT ändert Quelle. Destination NAT ändert Ziel. Private IPv4-Adressen sind intern gedacht. Öffentliche IP-Adressen sind im Internet routbar. CGNAT erschwert eingehende Verbindungen. Hairpin NAT = intern über öffentliche Adresse. Split DNS = intern andere Antwort als extern. Jeder offene Port ist ein Risiko. Firewall-Regeln dokumentieren und regelmäßig prüfen. # 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. # 11.3 NAT, PAT und Portweiterleitung im Detail NAT und PAT werden in IPv4-Netzwerken sehr häufig eingesetzt. Sie ermöglichen, dass interne private IP-Adressen mit externen Netzen kommunizieren können. NAT steht für: Network Address Translation PAT steht für: Port Address Translation Portweiterleitung wird genutzt, um einen internen Dienst von außen erreichbar zu machen. Merksatz: NAT übersetzt IP-Adressen. PAT übersetzt IP-Adressen und Ports. Portweiterleitung macht interne Dienste erreichbar. --- **Warum gibt es NAT?** IPv4-Adressen sind begrenzt. Deshalb werden in lokalen Netzwerken häufig private IPv4-Adressen verwendet. Diese privaten Adressen sind im Internet nicht direkt geroutet. Beispiele: 192.168.1.10 10.0.0.20 172.16.5.30 Damit solche Geräte trotzdem ins Internet können, übersetzt ein Router oder eine Firewall die privaten Adressen in eine öffentliche Adresse. Merksatz: NAT ermöglicht Internetzugang mit privaten IPv4-Adressen. --- **Private IPv4-Adressen** Private IPv4-Adressbereiche sind für interne Netze vorgesehen. | Bereich | CIDR | typische Nutzung | |---|---|---| | 10.0.0.0 bis 10.255.255.255 | 10.0.0.0/8 | große interne Netze | | 172.16.0.0 bis 172.31.255.255 | 172.16.0.0/12 | mittlere interne Netze | | 192.168.0.0 bis 192.168.255.255 | 192.168.0.0/16 | Heimnetze und kleine Netze | Diese Adressen sind im öffentlichen Internet nicht direkt erreichbar. Merksatz: Private IPv4-Adressen sind intern nutzbar, aber nicht öffentlich geroutet. --- **Öffentliche IPv4-Adresse** Eine öffentliche IPv4-Adresse ist im Internet routbar. Sie wird zum Beispiel vom Internetanbieter zugewiesen. Beispiel: Router WAN-Adresse: öffentliche IPv4-Adresse Client im LAN: private IPv4-Adresse Der Router übersetzt beim Internetzugriff die private Adresse in die öffentliche Adresse. Merksatz: Öffentliche IP-Adresse ist im Internet sichtbar. --- **NAT-Grundprinzip** Ein interner Client baut eine Verbindung ins Internet auf. Vor NAT: Quelle: 192.168.10.50 Ziel: 93.184.216.34 Nach NAT: Quelle: öffentliche IP des Routers Ziel: 93.184.216.34 Der externe Server sieht nicht die private IP des Clients, sondern die öffentliche IP der Firewall oder des Routers. Merksatz: NAT versteckt private Quelladressen hinter einer öffentlichen Adresse. --- **NAT-Tabelle** Damit Antworten wieder zum richtigen internen Client zurückkommen, führt das NAT-Gerät eine Zuordnungstabelle. Dort steht vereinfacht: Interner Client mit internem Port gehört zu externer Verbindung mit übersetztem Port. Beispiel: | intern | extern sichtbar | Ziel | |---|---|---| | 192.168.10.50:50123 | 203.0.113.10:61001 | 93.184.216.34:443 | | 192.168.10.51:50200 | 203.0.113.10:61002 | 93.184.216.34:443 | Merksatz: NAT merkt sich, welche interne Verbindung zu welcher externen Verbindung gehört. --- **Source NAT** Source NAT ändert die Quelladresse. Typischer Fall: interner Client geht ins Internet. Vor Source NAT: Quelle: 192.168.10.50 Ziel: 93.184.216.34 Nach Source NAT: Quelle: öffentliche IP Ziel: 93.184.216.34 Merksatz: Source NAT ändert die Quelle. --- **Destination NAT** Destination NAT ändert die Zieladresse. Typischer Fall: externer Zugriff auf internen Dienst. Beispiel: öffentliche IP TCP 443 wird weitergeleitet an interner Webserver TCP 443 Vor Destination NAT: Ziel: öffentliche IP:443 Nach Destination NAT: Ziel: 192.168.10.20:443 Merksatz: Destination NAT ändert das Ziel. --- **PAT** PAT steht für: Port Address Translation PAT übersetzt zusätzlich Ports. Das ist besonders wichtig, wenn viele interne Geräte dieselbe öffentliche IPv4-Adresse verwenden. Beispiel: Client A: 192.168.10.10:50001 Client B: 192.168.10.11:50001 Extern kann beides über dieselbe öffentliche IP laufen, weil unterschiedliche übersetzte Ports genutzt werden. Merksatz: PAT macht viele interne Verbindungen über eine öffentliche IP möglich. --- **NAT und PAT vergleichen** | Begriff | Bedeutung | Beispiel | |---|---|---| | NAT | IP-Adresse wird übersetzt | 192.168.10.50 → öffentliche IP | | PAT | IP-Adresse und Port werden übersetzt | 192.168.10.50:50123 → öffentliche IP:61001 | | Source NAT | Quelle wird geändert | LAN → Internet | | Destination NAT | Ziel wird geändert | Internet → interner Server | | Portweiterleitung | externer Port wird intern weitergeleitet | WAN:443 → Server:443 | Merksatz: NAT = Adresse. PAT = Adresse plus Port. --- **Warum PAT so häufig ist** In Heimnetzen und kleinen Unternehmensnetzen gibt es oft nur eine öffentliche IPv4-Adresse. Trotzdem sollen viele Geräte gleichzeitig ins Internet. Beispiele: Notebook Smartphone Server Drucker Smart-TV NAS virtuelle Maschinen PAT unterscheidet diese Verbindungen über Ports. Merksatz: PAT löst das Problem, dass viele interne Geräte eine öffentliche IPv4-Adresse teilen. --- **Portweiterleitung** Portweiterleitung bedeutet: Ein Port auf der öffentlichen Adresse wird an ein internes Ziel weitergeleitet. Beispiel: öffentliche IP:443 → 192.168.10.20:443 Oder: öffentliche IP:8443 → 192.168.10.20:443 Portweiterleitung ist eine Form von Destination NAT. Merksatz: Portweiterleitung leitet externe Anfragen an interne Dienste weiter. --- **Beispiel: Webserver intern veröffentlichen** Situation: Interner Webserver: 192.168.10.20 Dienst: HTTPS TCP 443 Ziel: Benutzer aus dem Internet sollen den Webserver erreichen. Benötigt: DNS zeigt auf öffentliche IP. Portweiterleitung WAN:443 → 192.168.10.20:443. Firewall-Regel erlaubt TCP 443. Webserver hört auf TCP 443. Zertifikat passt zum Hostnamen. Merksatz: Externer Webzugriff braucht DNS, NAT, Firewall, Dienst und Zertifikat. --- **Portweiterleitung und Firewall-Regel** Eine Portweiterleitung allein reicht nicht immer. Man braucht oft zusätzlich eine Firewall-Regel. NAT-Regel: Wohin soll der Verkehr übersetzt werden? Firewall-Regel: Darf der Verkehr überhaupt durch? Beispiel: NAT: WAN:443 → Webserver:443 Firewall: Erlaube WAN → Webserver TCP 443 Wenn die Firewall blockiert, funktioniert der Zugriff trotz NAT nicht. Merksatz: NAT leitet um. Firewall erlaubt oder blockiert. --- **Portweiterleitung und DNS** Damit Benutzer einen Dienst bequem erreichen, wird meist ein DNS-Name genutzt. Beispiel: cloud.firma.de → öffentliche IP Dann leitet die Firewall weiter: öffentliche IP:443 → interner Server:443 Wenn DNS auf die falsche IP zeigt, erreicht der Benutzer den falschen Anschluss oder Server. Merksatz: DNS muss zur öffentlichen Adresse der Portweiterleitung passen. --- **Portweiterleitung und Zertifikate** Bei HTTPS muss das Zertifikat zum aufgerufenen Namen passen. Beispiel: Benutzer ruft auf: https://cloud.firma.de Zertifikat muss gültig sein für: cloud.firma.de Wenn DNS oder Portweiterleitung auf den falschen Server zeigt, kann ein falsches Zertifikat ausgeliefert werden. Merksatz: HTTPS-Veröffentlichung braucht passenden DNS-Namen und passendes Zertifikat. --- **Portweiterleitung und Reverse Proxy** Oft wird nicht jeder interne Dienst direkt veröffentlicht. Stattdessen zeigt die Portweiterleitung auf einen Reverse Proxy. Beispiel: öffentliche IP:443 → Reverse Proxy in DMZ Der Reverse Proxy leitet dann nach Hostname weiter: wiki.firma.de → interner Wiki-Server cloud.firma.de → interner Cloud-Server git.firma.de → interner Git-Server Merksatz: Reverse Proxy kann mehrere interne Webdienste über HTTPS bündeln. --- **Portweiterleitung und mehrere Dienste** Ein öffentlicher Port kann auf einer öffentlichen IP nur einmal eindeutig belegt werden. Beispiel: öffentliche IP:443 kann nicht gleichzeitig direkt auf drei verschiedene Server zeigen. Lösung: Reverse Proxy mit Hostnamen oder unterschiedliche externe Ports oder mehrere öffentliche IP-Adressen Merksatz: Ein Port auf einer IP kann nur eindeutig einem Ziel zugeordnet werden. --- **Externer Port und interner Port** Bei Portweiterleitung können externer und interner Port gleich oder unterschiedlich sein. Beispiel gleich: WAN:443 → Server:443 Beispiel unterschiedlich: WAN:8443 → Server:443 Das kann für Tests nützlich sein, sollte aber sauber dokumentiert werden. Merksatz: Externer Port und interner Port müssen nicht identisch sein. --- **Sicherheitsrisiko Portweiterleitung** Eine Portweiterleitung macht einen internen Dienst von außen erreichbar. Das erhöht die Angriffsfläche. Risiken: - Brute-Force-Angriffe - Ausnutzung von Schwachstellen - Fehlkonfiguration - veraltete Software - offene Adminoberflächen - schwache Passwörter - unnötige Dienste im Internet Merksatz: Jeder veröffentlichte Port ist ein potenzieller Angriffspunkt. --- **Was sollte man nicht direkt veröffentlichen?** Nicht direkt ins Internet gehören normalerweise: - SMB TCP 445 - RDP TCP 3389 - Datenbankports - Drucker - interne Adminoberflächen - Hypervisor-Management - NAS-Adminoberflächen - unsichere Webinterfaces - Telnet TCP 23 - unverschlüsseltes FTP Besser: VPN, Reverse Proxy, Zero-Trust-Zugriff, Bastion Host oder gezielte Zugriffsbeschränkung. Merksatz: Administrative und interne Dienste nicht direkt ins Internet öffnen. --- **Portweiterleitung und Quellbeschränkung** Eine Portweiterleitung kann sicherer werden, wenn nur bestimmte Quellen erlaubt sind. Beispiel: Nur Admin-IP darf SSH erreichen. Oder: Nur Partnernetz darf API erreichen. Vorteil: nicht jeder im Internet kann den Dienst erreichen. Merksatz: Wenn möglich, Zugriff auf bekannte Quellen beschränken. --- **Portweiterleitung und VPN** Oft ist VPN sicherer als direkte Portweiterleitung. Beispiel: Kein RDP direkt aus dem Internet. Stattdessen: Benutzer verbindet sich per VPN. Danach RDP intern nutzen. Vorteil: RDP-Port ist nicht öffentlich sichtbar. Merksatz: Für Administration lieber VPN statt direkter Portweiterleitung. --- **NAT ist keine echte Sicherheitsfunktion** NAT verhindert zwar, dass interne private Adressen direkt aus dem Internet erreichbar sind. Aber NAT ist nicht dasselbe wie eine Firewall. Eine Firewall prüft und steuert Verkehr bewusst. NAT übersetzt Adressen. Merksatz: NAT ist nicht automatisch Sicherheit. --- **NAT und IPv6** Bei IPv6 ist NAT normalerweise nicht in derselben Form nötig, weil es sehr viele öffentliche IPv6-Adressen gibt. IPv6-Netze arbeiten eher mit: - Routing - Firewall-Regeln - global eindeutigen Adressen - Prefix Delegation Wichtig: Ohne NAT sind Systeme nicht automatisch ungeschützt. Die Firewall bleibt entscheidend. Merksatz: IPv6 braucht meist weniger NAT, aber weiterhin Firewall-Regeln. --- **NAT und Protokollprobleme** Manche Protokolle sind schwierig mit NAT. Gründe: - IP-Adressen stehen im Protokollinhalt - mehrere Verbindungen werden verwendet - dynamische Ports werden genutzt - eingehende Rückverbindungen sind nötig Beispiele: FTP SIP bestimmte VPN-Protokolle ältere Anwendungen Merksatz: NAT kann Protokolle stören, die zusätzliche Verbindungsinformationen enthalten. --- **FTP und NAT** FTP kann mit NAT kompliziert sein, weil FTP Steuer- und Datenverbindungen verwendet. Typische Fehler: Login funktioniert, aber Dateiliste nicht. Dateiübertragung startet nicht. Passiver Portbereich ist nicht freigegeben. Server gibt falsche externe IP aus. Merksatz: FTP braucht bei NAT besondere Beachtung. --- **SIP und NAT** SIP wird häufig bei VoIP verwendet. SIP kann durch NAT Probleme bekommen, weil Adressen und Ports im Signalisierungsverkehr eine Rolle spielen. Mögliche Fehler: kein Audio nur einseitiges Audio Anrufaufbau scheitert Registrierung bricht ab Merksatz: VoIP-Protokolle können durch NAT besondere Probleme bekommen. --- **NAT Loopback** NAT Loopback ist ein anderer Begriff für Hairpin NAT. Es beschreibt, dass interne Clients über die öffentliche Adresse auf einen internen Dienst zugreifen. Beispiel: Client im LAN ruft cloud.firma.de auf. DNS liefert öffentliche IP. Router leitet Verbindung wieder zurück nach innen. Merksatz: NAT Loopback = Hairpin NAT. --- **Hairpin NAT** Hairpin NAT bedeutet: Ein interner Client nutzt die öffentliche Adresse, um einen internen Dienst zu erreichen. Ohne Hairpin NAT kann passieren: Dienst funktioniert extern, aber intern über denselben Namen nicht. Alternative: Split DNS Merksatz: Hairpin NAT hilft, wenn interne Clients öffentliche Namen verwenden. --- **Split DNS** Split DNS liefert intern und extern unterschiedliche DNS-Antworten. Beispiel: cloud.firma.de extern: öffentliche IP cloud.firma.de intern: interne IP Vorteil: interne Clients gehen direkt zum internen Ziel, ohne Hairpin NAT zu brauchen. Merksatz: Split DNS ist oft sauberer als Hairpin NAT. --- **CGNAT** CGNAT steht für: Carrier Grade NAT Dabei teilt der Provider eine öffentliche IPv4-Adresse auf mehrere Kunden auf. Der eigene Router bekommt dann keine echte öffentliche IPv4-Adresse. Folge: klassische eingehende Portweiterleitungen funktionieren oft nicht. Erkennbar oft daran: WAN-IP am Router ist privat oder aus speziellem Providerbereich, aber öffentliche IP im Internet ist eine andere. Merksatz: CGNAT verhindert häufig direkte eingehende IPv4-Verbindungen. --- **Lösungen bei CGNAT** Wenn eingehende Verbindungen wegen CGNAT nicht funktionieren, gibt es mögliche Alternativen: - echte öffentliche IPv4-Adresse beim Provider buchen - IPv6 verwenden - VPN zu einem externen Server - Cloud-Tunnel - Reverse SSH Tunnel - Zero-Trust-Tunnel - Hosting eines öffentlichen Einstiegspunkts Merksatz: Bei CGNAT braucht man oft Tunnel, IPv6 oder eine echte öffentliche IPv4-Adresse. --- **Double NAT** Double NAT bedeutet: Es gibt zwei NAT-Geräte hintereinander. Beispiel: Provider-Router macht NAT. Eigener Router macht ebenfalls NAT. Folgen: - Portweiterleitungen müssen auf beiden Geräten passen - Fehlersuche wird schwieriger - manche Protokolle machen Probleme - Gaming, VPN oder VoIP können gestört sein Merksatz: Double NAT erschwert eingehende Verbindungen. --- **NAT und Rückweg** Damit NAT funktioniert, muss der Rückverkehr wieder über dasselbe NAT-Gerät laufen. Wenn Rückwege anders laufen, kann die Zuordnung fehlen. Das betrifft besonders: - mehrere Router - mehrere Firewalls - asymmetrisches Routing - mehrere Internetanschlüsse - komplexe VPN-Setups Merksatz: NAT braucht passenden Rückweg. --- **Portweiterleitung testen** Beim Testen einer Portweiterleitung sollte man prüfen: DNS zeigt auf richtige öffentliche IP? öffentliche IP ist wirklich am Anschluss? CGNAT ausgeschlossen? NAT-Regel korrekt? Firewall-Regel korrekt? Zielserver erreichbar? Dienst läuft auf Zielport? Zielserver-Firewall erlaubt Zugriff? Zertifikat passt? Logs zeigen Verbindungsversuch? Merksatz: Portweiterleitung braucht mehrere passende Bausteine. --- **Typisches Fehlerbild: Portweiterleitung funktioniert nicht** Mögliche Ursachen: - falsche öffentliche IP - CGNAT - Double NAT - Portweiterleitung auf falsches Ziel - falscher interner Port - Firewall-Regel fehlt - Dienst läuft nicht - Host-Firewall blockiert - DNS zeigt falsch - Provider blockiert Port - Test aus internem Netz ohne Hairpin NAT - Zertifikatsproblem bei HTTPS Merksatz: Portweiterleitungsfehler sind oft NAT-, Firewall-, DNS- oder Dienstprobleme. --- **Fehlerbild: Von außen geht es, von innen nicht** Mögliche Ursachen: - Hairpin NAT fehlt - internes DNS zeigt falsch - Split DNS fehlt - interne Firewall blockiert - Zertifikat passt intern nicht - interner Client nutzt anderen Pfad Lösungsideen: Split DNS einrichten oder Hairpin NAT aktivieren Merksatz: Extern funktioniert, intern nicht: Hairpin NAT oder Split DNS prüfen. --- **Fehlerbild: Von innen geht es, von außen nicht** Mögliche Ursachen: - NAT-Regel fehlt - Firewall-Regel fehlt - externe DNS-Antwort falsch - Dienst nur intern gebunden - öffentliche IP falsch - Provider blockiert - CGNAT - Zertifikat oder Reverse Proxy falsch - Zielserver-Firewall blockiert Merksatz: Intern funktioniert, extern nicht: öffentliche Erreichbarkeit prüfen. --- **Fehlerbild: Falscher interner Dienst antwortet** Mögliche Ursachen: - Portweiterleitung zeigt auf falschen Host - Reverse Proxy leitet falsch weiter - DNS zeigt auf falsche IP - Host-Header passt nicht - falscher virtueller Host - alte NAT-Regel greift vorher - Regelreihenfolge falsch Merksatz: Falscher Dienst bedeutet oft: DNS, NAT oder Reverse Proxy falsch. --- **Fehlerbild: HTTPS zeigt falsches Zertifikat** Mögliche Ursachen: - DNS zeigt auf falsche öffentliche IP - Portweiterleitung zeigt auf falschen Server - Reverse Proxy liefert falsches Zertifikat - Hostname passt nicht - falscher virtueller Host - internes und externes DNS unterscheiden sich falsch Merksatz: Falsches Zertifikat kann durch falsches NAT oder DNS entstehen. --- **NAT und Dokumentation** NAT-Regeln sollten dokumentiert werden. Wichtige Angaben: - öffentliche IP - externer Port - internes Ziel - interner Port - Protokoll - Zweck - Verantwortlicher - Datum - Sicherheitsbewertung - zugehörige Firewall-Regel - DNS-Name - Zertifikat Merksatz: NAT-Regeln ohne Dokumentation werden schnell unübersichtlich. --- **Typische NAT-Dokumentation** Beispiel: | DNS-Name | extern | intern | Zweck | |---|---|---|---| | wiki.firma.de | WAN TCP 443 | 192.168.10.20 TCP 443 | Wiki | | vpn.firma.de | WAN UDP 51820 | 192.168.10.5 UDP 51820 | VPN | | mail.firma.de | WAN TCP 25 | 192.168.20.10 TCP 25 | Mail | Merksatz: DNS, externer Port, internes Ziel und Zweck zusammen dokumentieren. --- **NAT und Sicherheit prüfen** Regelmäßige Prüfung: Welche Ports sind öffentlich offen? Werden alle Weiterleitungen noch benötigt? Sind die Zielsysteme aktuell? Gibt es alte Testregeln? Sind Adminoberflächen öffentlich? Sind Quellbeschränkungen möglich? Wird TLS genutzt? Gibt es Logs? Gibt es Monitoring? Ist ein VPN besser? Merksatz: Öffentlich erreichbare Dienste regelmäßig prüfen. --- **Was NAT nicht macht** NAT macht nicht automatisch: - Dienst sicher - Benutzer authentifizieren - Schwachstellen schließen - TLS einrichten - Firewall-Regeln ersetzen - DNS korrekt setzen - Zertifikate passend machen - Logs auswerten - Angriffe verhindern Merksatz: NAT ist Adressübersetzung, kein vollständiger Schutz. --- **Einordnung in das OSI-Modell** | Thema | Schicht | |---|---:| | NAT | 3 / 4 | | PAT | 3 / 4 | | Source NAT | 3 / 4 | | Destination NAT | 3 / 4 | | Portweiterleitung | 3 / 4 | | IP-Adresse | 3 | | Port | 4 | | Firewall-Regel | 3 / 4 / je nach Firewall auch 7 | | DNS-Name | 7 | | HTTPS-Zertifikat | 6 / 7 | | Reverse Proxy | 7 | Merksatz: NAT betrifft IP-Adressen und Ports, also vor allem Schicht 3 und 4. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was bedeutet NAT? - Warum wird NAT bei IPv4 verwendet? - Was ist PAT? - Was ist der Unterschied zwischen NAT und PAT? - Was ist Source NAT? - Was ist Destination NAT? - Was ist eine Portweiterleitung? - Warum reicht NAT allein nicht als Firewall? - Warum braucht man zusätzlich Firewall-Regeln? - Was ist Hairpin NAT? - Was ist Split DNS? - Was ist CGNAT? - Warum funktioniert eine Portweiterleitung bei CGNAT oft nicht? - Warum kann Double NAT Probleme verursachen? - Warum sollte man RDP oder SMB nicht direkt weiterleiten? - Wie prüft man eine nicht funktionierende Portweiterleitung? --- **Typische Prüfungsfallen** NAT ist nicht Firewall. Firewall ist nicht NAT. NAT übersetzt IP-Adressen. PAT übersetzt IP-Adressen und Ports. Source NAT ändert die Quelle. Destination NAT ändert das Ziel. Portweiterleitung ist Destination NAT. Private IPv4-Adressen sind nicht direkt im Internet geroutet. Portweiterleitung macht interne Dienste extern erreichbar. NAT-Regel allein reicht nicht, wenn Firewall blockiert. Firewall-Regel allein reicht nicht, wenn NAT fehlt. DNS muss auf die richtige öffentliche IP zeigen. HTTPS braucht passendes Zertifikat. Ein öffentlicher Port auf einer IP kann nur eindeutig weitergeleitet werden. Reverse Proxy kann mehrere Webdienste über einen Port bündeln. CGNAT verhindert oft eingehende IPv4-Verbindungen. Double NAT erschwert Portweiterleitungen. Hairpin NAT betrifft interne Clients mit öffentlicher Adresse. Split DNS kann Hairpin NAT vermeiden. NAT ist keine vollständige Sicherheitsmaßnahme. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | NAT | Network Address Translation | | PAT | Port Address Translation | | Source NAT | Quelladresse wird übersetzt | | Destination NAT | Zieladresse wird übersetzt | | Portweiterleitung | externer Port wird an internes Ziel weitergeleitet | | private IP-Adresse | interne nicht öffentlich geroutete Adresse | | öffentliche IP-Adresse | im Internet routbare Adresse | | NAT-Tabelle | Zuordnung interner und externer Verbindungen | | Hairpin NAT | interner Zugriff über öffentliche Adresse | | NAT Loopback | anderer Begriff für Hairpin NAT | | Split DNS | intern und extern unterschiedliche DNS-Antwort | | CGNAT | Provider-NAT für mehrere Kunden | | Double NAT | zwei NAT-Geräte hintereinander | | Reverse Proxy | leitet Anfragen anhand von Hostnamen weiter | | WAN-Port | externer Port auf öffentlicher Seite | | interner Port | Port auf dem internen Zielsystem | | Quellport | Port des sendenden Systems | | Zielport | Port des Ziel-Dienstes | --- **IHK-sichere Kurzformulierung** NAT steht für Network Address Translation und übersetzt IP-Adressen, häufig private IPv4-Adressen in eine öffentliche IPv4-Adresse. PAT steht für Port Address Translation und übersetzt zusätzlich Ports, damit mehrere interne Geräte gleichzeitig eine öffentliche Adresse nutzen können. Source NAT ändert die Quelladresse und wird typischerweise für ausgehenden Internetverkehr verwendet. Destination NAT ändert die Zieladresse und wird häufig für Portweiterleitungen genutzt. Eine Portweiterleitung macht einen internen Dienst von außen erreichbar, benötigt aber neben der NAT-Regel auch passende Firewall-Regeln, einen laufenden Dienst, korrekte DNS-Einträge und bei HTTPS ein passendes Zertifikat. NAT ist keine vollständige Sicherheitsmaßnahme und ersetzt keine Firewall. --- **Merksätze** NAT = Network Address Translation. PAT = Port Address Translation. NAT übersetzt IP-Adressen. PAT übersetzt IP-Adressen und Ports. Source NAT ändert Quelle. Destination NAT ändert Ziel. Portweiterleitung ist Destination NAT. Private IPv4-Adressen sind intern. Öffentliche IPv4-Adressen sind im Internet routbar. NAT ermöglicht Internetzugang mit privaten IPv4-Adressen. PAT ermöglicht viele Clients über eine öffentliche IP. NAT-Tabelle merkt sich Zuordnungen. NAT ist keine Firewall. Firewall ist kein NAT. NAT-Regel und Firewall-Regel müssen zusammenpassen. Portweiterleitung erhöht die Angriffsfläche. Admin-Dienste nicht direkt ins Internet öffnen. RDP nicht direkt weiterleiten. SMB nicht direkt weiterleiten. SFTP oder VPN sicherer als unverschlüsseltes FTP. Reverse Proxy bündelt Webdienste. DNS muss zur öffentlichen IP passen. Zertifikat muss zum Hostnamen passen. CGNAT verhindert oft eingehende IPv4-Verbindungen. Double NAT erschwert Portweiterleitungen. Hairpin NAT = intern über öffentliche Adresse. Split DNS liefert intern andere Antworten. NAT braucht passenden Rückweg. NAT ersetzt kein Sicherheitskonzept. # 11.4 DMZ und Sicherheitszonen im Detail DMZ steht für: Demilitarized Zone Eine DMZ ist ein separates Netzwerksegment für Dienste, die von außen erreichbar sein müssen. Typische Dienste in einer DMZ: - Webserver - Reverse Proxy - Mailgateway - VPN-Gateway - öffentlicher DNS-Server - öffentliche API - Proxyserver - Bastion Host Merksatz: DMZ = eigenes Netz für öffentlich erreichbare Dienste. --- **Warum braucht man eine DMZ?** Öffentlich erreichbare Dienste sind stärker gefährdet als rein interne Dienste. Beispiel: Ein Webserver ist aus dem Internet erreichbar. Wenn dieser Webserver kompromittiert wird, soll der Angreifer nicht direkt Zugriff auf das interne LAN bekommen. Die DMZ trennt deshalb öffentliche Dienste vom internen Netz. Merksatz: Eine DMZ begrenzt den Schaden, wenn ein öffentlich erreichbarer Dienst angegriffen wird. --- **Grundidee einer DMZ** Eine DMZ liegt logisch zwischen: externem Netz und internem Netz Vereinfacht: Internet → Firewall → DMZ → Firewall-Regeln → internes LAN Die DMZ ist nicht so vertrauenswürdig wie das interne LAN. Aber sie ist kontrollierter als das Internet. Merksatz: DMZ liegt kontrolliert zwischen außen und innen. --- **DMZ ist nicht das interne LAN** Ein häufiger Fehler ist: Ein öffentlich erreichbarer Server steht direkt im internen LAN. Das ist riskant. Besser: öffentliche Dienste in DMZ stellen und Zugriffe ins LAN stark einschränken. Warum? Wird ein DMZ-System kompromittiert, soll der Angreifer nicht automatisch interne Clients, Server oder Verwaltungsdienste erreichen. Merksatz: Öffentliche Dienste gehören nicht ungefiltert ins interne LAN. --- **DMZ als Sicherheitszone** Eine DMZ ist eine Sicherheitszone. Eine Sicherheitszone ist ein Netzbereich mit eigenem Schutzbedarf. Typische Zonen: - WAN - LAN - DMZ - Servernetz - Managementnetz - Gastnetz - IoT-Netz - VPN-Zone Zwischen diesen Zonen gelten Firewall-Regeln. Merksatz: Sicherheitszonen trennen Netze nach Vertrauensniveau. --- **Vertrauensniveau von Zonen** Nicht jedes Netz ist gleich vertrauenswürdig. Beispiel: | Zone | Vertrauensniveau | Beispiel | |---|---|---| | WAN | sehr gering | Internet | | Gastnetz | gering | Besuchergeräte | | IoT-Netz | gering bis mittel | Kameras, Sensoren | | DMZ | mittel / eingeschränkt | öffentliche Dienste | | LAN | höher | interne Clients | | Servernetz | hoch | interne Server | | Managementnetz | sehr hoch | Adminzugänge | Merksatz: Je kritischer eine Zone ist, desto strenger müssen Zugriffe kontrolliert werden. --- **Typischer Drei-Zonen-Aufbau** Ein klassischer Aufbau besteht aus drei Zonen: WAN DMZ LAN WAN: externes Netz oder Internet DMZ: öffentliche Dienste LAN: internes Unternehmensnetz Merksatz: Drei-Zonen-Aufbau = WAN, DMZ, LAN. --- **Beispielaufbau** Vereinfacht: Internet | Firewall / \ DMZ LAN Web Clients Mail interne Server Die Firewall kontrolliert, welche Zone mit welcher Zone kommunizieren darf. Merksatz: Die Firewall ist der kontrollierte Übergang zwischen den Zonen. --- **Regelidee Internet zur DMZ** Vom Internet zur DMZ sollte nur erlaubt sein, was wirklich öffentlich erreichbar sein muss. Beispiele: | Quelle | Ziel | Dienst | Aktion | |---|---|---|---| | Internet | Reverse Proxy DMZ | HTTPS TCP 443 | erlauben | | Internet | Mailgateway DMZ | SMTP TCP 25 | erlauben | | Internet | VPN-Gateway DMZ | VPN-Port | erlauben | | Internet | DMZ-Server | SSH TCP 22 | blockieren | | Internet | interne Server | any | blockieren | Merksatz: Internet darf nur notwendige öffentliche Dienste in der DMZ erreichen. --- **Regelidee DMZ zum LAN** Von der DMZ ins LAN sollte sehr wenig erlaubt sein. Beispiele: | Quelle | Ziel | Dienst | Aktion | |---|---|---|---| | Reverse Proxy DMZ | interner Webdienst | TCP 8080 | erlauben | | Webserver DMZ | Datenbankserver | TCP 5432 | nur wenn nötig | | Mailgateway DMZ | interner Mailserver | SMTP | nur gezielt | | DMZ allgemein | LAN allgemein | any | blockieren | Wichtig: DMZ darf keine freie Brücke ins interne Netz sein. Merksatz: Von DMZ ins LAN nur das zwingend Notwendige erlauben. --- **Regelidee LAN zur DMZ** Das interne LAN darf je nach Bedarf Dienste in der DMZ erreichen. Beispiele: interne Clients → DMZ-Webserver HTTPS Admin-Netz → DMZ-Server SSH Monitoring → DMZ-Systeme SNMP Aber auch hier gilt: nicht alles für jeden erlauben. Merksatz: Auch LAN zur DMZ sollte gezielt geregelt werden. --- **Regelidee Management zur DMZ** Administration sollte nicht aus beliebigen Netzen erlaubt sein. Besser: Managementnetz oder Bastion Host oder VPN-Adminzugang Beispiel: Managementnetz → DMZ-Server SSH TCP 22 erlauben Aber nicht: gesamtes LAN → DMZ-Server SSH erlauben Und erst recht nicht: Internet → DMZ-Server SSH erlauben Merksatz: Administration nur aus kontrollierten Managementbereichen erlauben. --- **DMZ und Reverse Proxy** Ein Reverse Proxy steht häufig in der DMZ. Er nimmt externe HTTPS-Anfragen entgegen und leitet sie an interne Dienste weiter. Beispiel: Internet → Reverse Proxy DMZ → interner Wiki-Server Vorteile: - zentrale TLS-Verwaltung - weniger direkte Veröffentlichung interner Server - mehrere Dienste über eine öffentliche IP - Zugriffskontrolle - bessere Protokollierung - Trennung zwischen extern und intern Merksatz: Reverse Proxy in der DMZ schützt interne Webdienste besser als direkte Freigabe. --- **DMZ und Webserver** Ein Webserver in der DMZ kann öffentliche Webseiten bereitstellen. Wichtig: Der Webserver sollte nur die internen Systeme erreichen, die er wirklich braucht. Beispiel: Webserver braucht Datenbankzugriff. Dann gilt: Webserver DMZ → Datenbankserver TCP 5432 erlauben Aber nicht: Webserver DMZ → gesamtes LAN any erlauben Merksatz: Webserver in DMZ nur mit notwendigen Backend-Zugriffen ausstatten. --- **DMZ und Mailgateway** Ein Mailgateway in der DMZ kann E-Mails aus dem Internet annehmen. Typische Aufgabe: Internet → Mailgateway DMZ Mailgateway prüft Spam und Malware Mailgateway leitet an internen Mailserver weiter Vorteil: Der interne Mailserver steht nicht direkt im Internet. Merksatz: Mailgateway in der DMZ schützt interne Mailserver. --- **DMZ und VPN-Gateway** Ein VPN-Gateway kann in der DMZ stehen. Ablauf: externer Benutzer verbindet sich zum VPN-Gateway nach erfolgreicher Anmeldung erhält er Zugriff auf erlaubte interne Ressourcen Wichtig: VPN-Zugriff darf nicht automatisch das gesamte LAN erlauben. Besser: VPN-Benutzer in eigene Zone einordnen und gezielte Regeln setzen. Merksatz: VPN-Gateway kann in der DMZ stehen, aber VPN-Rechte müssen begrenzt werden. --- **DMZ und öffentlicher DNS** Ein öffentlicher DNS-Server kann in einer DMZ stehen, wenn eine Organisation eigene öffentliche DNS-Zonen bereitstellt. Wichtig: öffentlicher DNS sollte nur öffentliche Informationen enthalten. Interne Servernamen sollten nicht öffentlich sichtbar sein. Merksatz: Öffentlicher DNS darf keine internen Strukturen verraten. --- **DMZ und Bastion Host** Ein Bastion Host ist ein besonders abgesicherter Sprungserver. Er kann genutzt werden, um administrative Zugriffe auf DMZ-Systeme zu bündeln. Ablauf: Admin → VPN oder Managementnetz → Bastion Host → DMZ-System Vorteile: - zentrale Kontrolle - bessere Protokollierung - weniger direkte Adminzugänge - zusätzliche Sicherheitsprüfung Merksatz: Bastion Host bündelt und kontrolliert Adminzugriffe. --- **Bastion Host ist besonders kritisch** Ein Bastion Host hat oft Zugriff auf wichtige Systeme. Deshalb muss er besonders geschützt werden. Maßnahmen: - MFA - starke Authentifizierung - nur Admins erlauben - Protokollierung - regelmäßige Updates - keine unnötigen Dienste - harte Firewall-Regeln - Monitoring - getrennte Admin-Konten Merksatz: Bastion Host stark absichern, weil er ein zentraler Zugangspunkt ist. --- **DMZ und Datenbankserver** Datenbankserver sollten normalerweise nicht direkt in der öffentlichen DMZ stehen. Besser: Datenbank im internen Servernetz und nur gezielter Zugriff vom Webserver oder Anwendungsserver Beispiel: Webserver DMZ → Datenbankserver TCP 5432 Wichtig: kein allgemeiner Zugriff von Internet oder DMZ auf Datenbank. Merksatz: Datenbanken nicht öffentlich platzieren. --- **DMZ und interne Daten** DMZ-Systeme sollten möglichst wenig interne Daten enthalten. Warum? Sie sind stärker exponiert. Wenn sensible Daten in der DMZ liegen, ist das Risiko bei einem Angriff höher. Besser: DMZ-Systeme nur mit notwendigen Daten ausstatten und interne Datenbanken geschützt halten. Merksatz: In der DMZ nur Daten, die dort wirklich benötigt werden. --- **DMZ und Protokollierung** DMZ-Systeme sollten gut protokolliert werden. Wichtige Logs: - Firewall-Logs - Webserver-Logs - Reverse-Proxy-Logs - Authentifizierungslogs - Systemlogs - IDS/IPS-Logs - VPN-Logs - Mailgateway-Logs Logs helfen bei: - Angriffserkennung - Fehlersuche - Nachvollziehbarkeit - Sicherheitsanalyse Merksatz: DMZ-Systeme brauchen gute Logs. --- **DMZ und Monitoring** DMZ-Systeme sollten überwacht werden. Typische Prüfwerte: - Erreichbarkeit - CPU - RAM - Speicherplatz - Dienste - Zertifikate - Loggröße - ungewöhnliche Verbindungen - fehlgeschlagene Logins - Updates - offene Ports Merksatz: DMZ-Systeme müssen aktiv überwacht werden. --- **DMZ und IDS/IPS** IDS steht für: Intrusion Detection System IPS steht für: Intrusion Prevention System IDS erkennt verdächtigen Verkehr. IPS kann verdächtigen Verkehr zusätzlich blockieren. In einer DMZ können IDS/IPS-Systeme helfen, Angriffe auf öffentliche Dienste zu erkennen. Merksatz: IDS erkennt. IPS blockiert zusätzlich. --- **DMZ und WAF** WAF steht für: Web Application Firewall Eine WAF schützt Webanwendungen auf Anwendungsebene. Sie prüft zum Beispiel HTTP-Anfragen auf: - SQL-Injection - Cross-Site Scripting - ungewöhnliche Muster - bekannte Angriffsversuche - fehlerhafte Requests Eine WAF ersetzt keine sichere Anwendung, kann aber zusätzlichen Schutz bieten. Merksatz: WAF schützt Webanwendungen auf Schicht 7. --- **DMZ und TLS** Öffentliche Dienste in der DMZ nutzen häufig TLS. Beispiele: HTTPS SMTPS IMAPS LDAPS VPN mit Zertifikaten Wichtig: Zertifikate aktuell halten private Schlüssel schützen TLS-Versionen sicher konfigurieren Zertifikatskette vollständig liefern Merksatz: Öffentliche Dienste brauchen saubere TLS-Konfiguration. --- **TLS-Terminierung in der DMZ** TLS-Terminierung bedeutet: TLS endet am Reverse Proxy oder Load Balancer. Ablauf: Client → HTTPS → Reverse Proxy DMZ Reverse Proxy → HTTP oder HTTPS → Backend Vorteile: - zentrale Zertifikatsverwaltung - Entlastung der Backendserver - bessere Kontrolle - einheitliche Sicherheitsrichtlinien Wichtig: Die interne Verbindung sollte je nach Schutzbedarf ebenfalls gesichert werden. Merksatz: TLS-Terminierung beendet TLS an einem zentralen Punkt. --- **TLS Passthrough** TLS Passthrough bedeutet: Die TLS-Verbindung wird durchgereicht, ohne am Proxy entschlüsselt zu werden. Ablauf: Client → TLS → Proxy → TLS → Backend Vorteil: Ende der TLS-Verbindung liegt am Backend. Nachteil: Proxy kann Inhalte weniger gut prüfen oder steuern. Merksatz: TLS Passthrough reicht verschlüsselten Verkehr weiter. --- **DMZ und Updates** DMZ-Systeme sind oft exponiert. Deshalb sind Updates besonders wichtig. Betroffen sind: - Betriebssystem - Webserver - Reverse Proxy - Anwendung - Frameworks - Bibliotheken - VPN-Software - Mailgateway - TLS-Komponenten Merksatz: Exponierte Systeme müssen besonders konsequent aktualisiert werden. --- **DMZ und Härtung** Härtung bedeutet: Systeme sicher konfigurieren und unnötige Angriffsflächen reduzieren. Maßnahmen: - unnötige Dienste deaktivieren - Standardpasswörter ändern - Adminzugänge beschränken - Updates einspielen - Dateirechte prüfen - sichere TLS-Konfiguration - Logging aktivieren - nur notwendige Ports öffnen - Dienstkonten begrenzen Merksatz: Härtung reduziert Angriffsfläche. --- **DMZ und Least Privilege** Auch in der DMZ gilt: nur notwendige Rechte vergeben. Beispiele: Webdienstkonto braucht keinen Domain-Admin. Reverse Proxy braucht nur Zugriff auf definierte Backends. Monitoring braucht nur Leserechte. Adminzugriff nur für Admins. Merksatz: Least Privilege gilt auch für Dienste und Server. --- **DMZ und Netzwerksegmentierung** Netzwerksegmentierung bedeutet: Netzbereiche werden getrennt, damit nicht alle Systeme frei miteinander kommunizieren können. Die DMZ ist ein Beispiel für Segmentierung. Weitere Segmentierung: - Servernetz - Datenbanknetz - Managementnetz - Backupnetz - Gastnetz - IoT-Netz Merksatz: Segmentierung begrenzt Bewegungsfreiheit bei Angriffen. --- **Laterale Bewegung** Laterale Bewegung bedeutet: Ein Angreifer bewegt sich nach einem ersten Einbruch weiter im Netzwerk. Beispiel: Angriff auf Webserver in DMZ. Danach Versuch, interne Server oder Datenbanken zu erreichen. Segmentierung und Firewall-Regeln sollen das erschweren. Merksatz: DMZ soll laterale Bewegung ins LAN erschweren. --- **DMZ und Zero Trust** Zero Trust bedeutet vereinfacht: keinem Zugriff automatisch vertrauen. Auch DMZ-Systeme werden nicht automatisch als sicher betrachtet. Prinzipien: - Identität prüfen - Zugriff begrenzen - Verbindungen protokollieren - nur notwendige Dienste erlauben - Systeme überwachen - Rechte regelmäßig prüfen Merksatz: Auch innerhalb des Netzes nicht blind vertrauen. --- **DMZ und Hochverfügbarkeit** Öffentliche Dienste sollen oft zuverlässig erreichbar sein. Möglichkeiten: - zwei Firewalls - zwei Reverse Proxys - Load Balancer - redundante Internetanschlüsse - mehrere Server - Monitoring - automatischer Failover - regelmäßige Backups Merksatz: DMZ-Dienste brauchen je nach Kritikalität Verfügbarkeit und Redundanz. --- **DMZ und Backup** DMZ-Systeme brauchen Backups, aber Backups dürfen nicht unsicher erreichbar sein. Wichtig: - Backupzugriff einschränken - Backupdaten schützen - keine Schreibrechte aus DMZ auf zentrale Backups ohne Kontrolle - Wiederherstellung testen - Ransomware-Risiko beachten Merksatz: DMZ-Systeme sichern, aber Backup-Infrastruktur schützen. --- **DMZ und Datenfluss** Bei einer DMZ muss man Datenflüsse genau kennen. Fragen: Wer spricht mit wem? Welche Anwendung? Welcher Port? Welche Richtung? Welche Daten? Wie sensibel sind die Daten? Wird verschlüsselt? Wird protokolliert? Ist der Zugriff notwendig? Merksatz: DMZ-Regeln entstehen aus klaren Datenflüssen. --- **Datenflussdiagramm für DMZ** Ein einfaches Datenflussdiagramm kann zeigen: Internet → Reverse Proxy TCP 443 Reverse Proxy → interner Webdienst TCP 8080 interner Webdienst → Datenbank TCP 5432 Monitoring → Reverse Proxy SNMP oder Agent-Port Admin-Netz → Reverse Proxy SSH So erkennt man, welche Regeln wirklich nötig sind. Merksatz: Datenflüsse sichtbar machen, bevor Regeln erstellt werden. --- **DMZ und Richtung der Verbindungen** Die Richtung der Verbindung ist wichtig. Beispiel: Internet startet Verbindung zum Reverse Proxy. Reverse Proxy startet Verbindung zum Backend. Backend sollte normalerweise nicht beliebig Verbindungen ins Internet starten. Firewall-Regeln müssen nach der tatsächlichen Verbindungsrichtung erstellt werden. Merksatz: Regeln nach Verbindungsstart planen. --- **DMZ und ausgehender Verkehr** Auch ausgehender Verkehr aus der DMZ sollte kontrolliert werden. Warum? Ein kompromittiertes DMZ-System könnte versuchen: - Schadsoftware nachzuladen - Daten abzuziehen - Verbindung zu Command-and-Control-Servern aufzubauen - interne Systeme zu scannen - Spam zu versenden Merksatz: DMZ outbound nicht blind erlauben. --- **DMZ und DNS** DMZ-Systeme brauchen oft DNS. Aber: Sie sollten möglichst definierte DNS-Resolver nutzen. Regelidee: DMZ-Systeme → interner oder DMZ-DNS UDP/TCP 53 erlauben Nicht ideal: DMZ-Systeme → beliebige externe DNS-Server erlauben Merksatz: DNS aus der DMZ kontrollieren. --- **DMZ und NTP** DMZ-Systeme brauchen korrekte Uhrzeit. NTP ist wichtig für: - Zertifikate - Logs - Authentifizierung - Monitoring - Fehlersuche Regelidee: DMZ-Systeme → freigegebener NTP-Server UDP 123 Merksatz: DMZ-Systeme brauchen kontrollierte Zeitsynchronisation. --- **DMZ und Namenskonzept** Ein sauberes Namenskonzept hilft bei DMZ-Diensten. Beispiele: extern: www.firma.de vpn.firma.de mail.firma.de intern: reverseproxy01.dmz.firma.local mailgw01.dmz.firma.local Wichtig: öffentliche Namen, interne Namen und Zertifikate müssen zusammenpassen. Merksatz: DNS-Namen und Zertifikate sauber planen. --- **DMZ und interne Authentifizierung** Manchmal müssen DMZ-Dienste Benutzer gegen interne Verzeichnisdienste prüfen. Beispiel: Webanwendung in DMZ nutzt LDAP oder SSO. Problem: Direkter Zugriff aus DMZ auf interne Domain Controller kann riskant sein. Mögliche Lösungen: - gezielte LDAPS-Regeln - Reverse Proxy mit Authentifizierung - Federation / SSO - getrennte Identitätsdienste - Proxy-Dienst für Authentifizierung Merksatz: Authentifizierung aus der DMZ ins LAN nur gezielt und sicher erlauben. --- **DMZ und Datenbankzugriff** Wenn DMZ-Systeme Datenbankzugriff brauchen, sollte dieser stark begrenzt werden. Prüfen: Muss die Datenbank wirklich intern stehen? Welche Quelle darf zugreifen? Welcher Port? Welches Konto? Welche Rechte? Ist TLS nötig? Gibt es Protokollierung? Gibt es Eingabevalidierung in der Anwendung? Merksatz: Datenbankzugriff aus der DMZ ist kritisch. --- **DMZ und direkte Internetzugriffe** Nicht jedes DMZ-System braucht freien Internetzugang. Beispiele für notwendige ausgehende Verbindungen: Updateserver Zertifikatsprüfung Paketquellen Monitoring externe API Besser: gezielte Ziele erlauben oder Proxy nutzen Merksatz: DMZ-Systeme nicht beliebig ins Internet lassen. --- **DMZ und öffentliche APIs** Öffentliche APIs sollten besonders geschützt werden. Maßnahmen: - HTTPS - Authentifizierung - Autorisierung - Rate Limiting - Eingabevalidierung - Logging - Monitoring - WAF - API-Gateway - keine unnötigen Daten ausgeben Merksatz: Öffentliche API = stark exponierter Schicht-7-Dienst. --- **DMZ und Fehlersuche** Bei DMZ-Problemen prüft man systematisch: 1. DNS zeigt richtig? 2. öffentliche IP korrekt? 3. NAT oder Portweiterleitung korrekt? 4. Firewall-Regel WAN → DMZ korrekt? 5. Dienst in DMZ läuft? 6. Host-Firewall erlaubt Zugriff? 7. Zertifikat passt? 8. Proxy leitet korrekt weiter? 9. Regel DMZ → Backend korrekt? 10. Backend läuft? 11. Logs prüfen. Merksatz: DMZ-Fehlersuche braucht DNS, NAT, Firewall, Dienst und Backend. --- **Fehlerbild: Öffentlicher Webdienst nicht erreichbar** Mögliche Ursachen: - DNS zeigt auf falsche öffentliche IP - NAT-Regel fehlt - Firewall-Regel fehlt - Reverse Proxy down - Webserver hört nicht auf Port - Host-Firewall blockiert - Zertifikatfehler - falscher virtueller Host - Backend nicht erreichbar - Provider oder CGNAT-Problem Merksatz: Öffentlicher Webdienst braucht komplette Kette von DNS bis Backend. --- **Fehlerbild: Reverse Proxy zeigt 502** Mögliche Ursachen: - Backend läuft nicht - falscher Backend-Port - falsches Protokoll HTTP/HTTPS - Firewall DMZ → Backend blockiert - Backend-DNS falsch - Container-Name oder interner Hostname falsch - Backend antwortet ungültig - Timeout Merksatz: 502 bedeutet oft: Proxy erreicht Backend nicht sauber. --- **Fehlerbild: DMZ-Server erreicht LAN nicht** Mögliche Ursachen: - Firewall-Regel fehlt - falsche Richtung - falsches Ziel - falscher Port - Route fehlt - Rückweg fehlt - Zielserver-Firewall blockiert - DNS löst intern falsch auf - Regel durch frühere Blockregel verdeckt Merksatz: DMZ zu LAN nur gezielt erlauben und sauber prüfen. --- **Fehlerbild: DMZ-Server kann Updates nicht laden** Mögliche Ursachen: - kein ausgehender Internetzugang erlaubt - DNS nicht erlaubt - Proxy erforderlich - Zertifikatsprüfung schlägt fehl - NTP falsch und Zertifikat wirkt ungültig - Paketquelle blockiert - Firewall-Regel zu eng Merksatz: Auch ausgehender DMZ-Verkehr braucht passende Regeln. --- **Fehlerbild: Zertifikat passt intern, extern aber nicht** Mögliche Ursachen: - extern anderer Hostname - Reverse Proxy liefert falsches Zertifikat - DNS zeigt auf falsche IP - Split DNS falsch - Zertifikat enthält externen Namen nicht - SNI-Konfiguration falsch Merksatz: Zertifikat muss zum tatsächlich aufgerufenen Namen passen. --- **SNI kurz erklärt** SNI steht für: Server Name Indication SNI ermöglicht, dass ein Server mehrere TLS-Zertifikate für verschiedene Hostnamen auf derselben IP anbieten kann. Beispiel: wiki.firma.de cloud.firma.de git.firma.de alle über: dieselbe öffentliche IP und TCP 443 Der Client teilt beim TLS-Aufbau den gewünschten Hostnamen mit. Merksatz: SNI hilft bei mehreren HTTPS-Diensten auf einer IP. --- **DMZ und Prüfungsdenken** In Prüfungsaufgaben wird oft erwartet, dass man erkennt: Öffentliche Dienste gehören in die DMZ. Interne Systeme gehören nicht direkt ins Internet. DMZ-Systeme dürfen nur notwendige Verbindungen ins LAN aufbauen. Firewall-Regeln müssen Quelle, Ziel, Dienst und Richtung enthalten. NAT und Firewall-Regeln müssen zusammenpassen. Merksatz: DMZ-Aufgaben immer mit Zonen und Datenflüssen lösen. --- **Was eine DMZ nicht macht** Eine DMZ macht nicht automatisch: - Webserver sicher - Software aktuell - Passwörter stark - TLS korrekt - Anwendung fehlerfrei - Datenbank geschützt - Angriffe unmöglich - Logs ausgewertet - Backups vorhanden Eine DMZ reduziert Risiken, ersetzt aber keine weiteren Sicherheitsmaßnahmen. Merksatz: DMZ ist Netztrennung, kein vollständiges Sicherheitskonzept. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür steht DMZ? - Was ist der Zweck einer DMZ? - Welche Systeme gehören typischerweise in eine DMZ? - Warum stehen öffentliche Server besser in der DMZ als im LAN? - Welche Regeln braucht ein Webserver in der DMZ? - Warum sollte die DMZ nicht frei ins LAN dürfen? - Was ist ein Reverse Proxy in der DMZ? - Was ist ein Bastion Host? - Was ist der Unterschied zwischen LAN, WAN und DMZ? - Warum sind Sicherheitszonen sinnvoll? - Was bedeutet Netzwerksegmentierung? - Was ist laterale Bewegung? - Welche Rolle spielen Firewall-Regeln zwischen Zonen? - Warum muss auch ausgehender Verkehr aus der DMZ kontrolliert werden? - Warum ist Monitoring in der DMZ wichtig? --- **Typische Prüfungsfallen** DMZ steht für Demilitarized Zone. DMZ ist ein separates Netz. DMZ ist nicht das interne LAN. Öffentliche Dienste gehören besser in die DMZ. DMZ schützt das LAN durch Trennung. DMZ darf nicht ungefiltert ins LAN. Internet darf nur notwendige DMZ-Dienste erreichen. Adminzugriff auf DMZ nicht aus dem gesamten Internet erlauben. Reverse Proxy kann in der DMZ stehen. Mailgateway kann in der DMZ stehen. VPN-Gateway kann in der DMZ stehen. Datenbankserver normalerweise nicht öffentlich in die DMZ stellen. DMZ-Systeme brauchen Updates und Härtung. DMZ-Systeme brauchen Monitoring und Logs. Firewall-Regeln zwischen Zonen müssen Richtung beachten. DMZ outbound ebenfalls kontrollieren. NAT-Regeln und Firewall-Regeln müssen zusammenpassen. DMZ ersetzt keine sichere Anwendung. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | DMZ | separates Netz für öffentlich erreichbare Dienste | | Sicherheitszone | Netzbereich mit eigenem Schutzbedarf | | WAN | externes Netz oder Internet | | LAN | internes Netz | | Managementnetz | Netz für Administration | | Gastnetz | separates Netz für Gäste | | Reverse Proxy | nimmt Anfragen an und leitet an Backends weiter | | Mailgateway | Mailserver-Schutz- oder Weiterleitungssystem | | VPN-Gateway | Einstiegspunkt für VPN-Verbindungen | | Bastion Host | abgesicherter Sprungserver | | Segmentierung | Aufteilung in getrennte Netzbereiche | | laterale Bewegung | Bewegung eines Angreifers innerhalb des Netzes | | IDS | erkennt Angriffe | | IPS | erkennt und blockiert Angriffe | | WAF | Web Application Firewall | | TLS-Terminierung | TLS endet am Proxy oder Load Balancer | | TLS Passthrough | TLS wird verschlüsselt weitergereicht | | SNI | Hostname-Anzeige beim TLS-Aufbau | | Härtung | sichere Konfiguration eines Systems | --- **IHK-sichere Kurzformulierung** Eine DMZ, also Demilitarized Zone, ist ein separates Netzwerksegment für Dienste, die aus dem Internet erreichbar sein müssen. Typische Systeme in einer DMZ sind Webserver, Reverse Proxys, Mailgateways oder VPN-Gateways. Der Zweck einer DMZ besteht darin, öffentliche Dienste vom internen LAN zu trennen und dadurch das interne Netz besser zu schützen. Zwischen WAN, DMZ und LAN werden gezielte Firewall-Regeln eingerichtet. Aus dem Internet sollten nur notwendige Dienste in der DMZ erreichbar sein, und von der DMZ ins interne LAN sollten nur zwingend erforderliche Verbindungen erlaubt werden. Eine DMZ reduziert Risiken, ersetzt aber keine Updates, Härtung, sichere Anwendungen, Monitoring oder Protokollierung. --- **Merksätze** DMZ = Demilitarized Zone. DMZ = separates Netz für öffentliche Dienste. DMZ ist nicht LAN. DMZ liegt zwischen Internet und internem Netz. Öffentliche Dienste gehören besser in die DMZ. DMZ schützt internes LAN durch Trennung. Internet → DMZ nur notwendige Dienste erlauben. Internet → LAN blockieren. DMZ → LAN nur zwingend notwendige Verbindungen erlauben. LAN → DMZ gezielt erlauben. Adminzugriff nur aus Managementnetz oder über Bastion Host. Reverse Proxy kann in der DMZ stehen. Mailgateway kann in der DMZ stehen. VPN-Gateway kann in der DMZ stehen. Datenbanken nicht direkt öffentlich platzieren. DMZ outbound kontrollieren. DNS und NTP für DMZ gezielt erlauben. DMZ-Systeme brauchen Updates. DMZ-Systeme brauchen Härtung. DMZ-Systeme brauchen Monitoring. DMZ-Systeme brauchen Logs. IDS erkennt Angriffe. IPS blockiert zusätzlich. WAF schützt Webanwendungen. TLS-Terminierung endet am Proxy. TLS Passthrough reicht TLS weiter. SNI ermöglicht mehrere HTTPS-Namen auf einer IP. Segmentierung begrenzt laterale Bewegung. DMZ ersetzt kein vollständiges Sicherheitskonzept. # 11.5 Fehlersuche bei Firewalls, NAT und DMZ Bei Problemen mit Firewalls, NAT und DMZ reicht es nicht, nur zu prüfen, ob ein Server grundsätzlich erreichbar ist. Man muss die komplette Verbindungskette prüfen: Client DNS Routing Firewall-Regel NAT-Regel Zielsystem Dienst Rückweg Logs Merksatz: Firewall-Fehlersuche bedeutet: Quelle, Ziel, Port, Richtung, NAT und Logs prüfen. --- **Grundidee der Fehlersuche** Bei Firewall- und NAT-Problemen ist die wichtigste Frage: Wo wird der Verkehr unterbrochen? Dazu prüft man Schritt für Schritt: Kommt die Anfrage beim richtigen Ziel an? Wird sie erlaubt oder blockiert? Wird sie richtig übersetzt? Antwortet der Dienst? Kommt die Antwort zurück? Merksatz: Nicht raten, sondern den Weg der Verbindung nachvollziehen. --- **Die wichtigsten Angaben vor der Fehlersuche** Vor der Fehlersuche braucht man genaue Informationen. Wichtige Fragen: Wer ist die Quelle? Was ist das Ziel? Welcher Dienst wird genutzt? Welcher Port wird genutzt? TCP oder UDP? In welche Richtung geht die Verbindung? Intern oder extern? Gibt es NAT? Gibt es eine DMZ? Gibt es einen Reverse Proxy? Welche Fehlermeldung erscheint? Merksatz: Ohne Quelle, Ziel, Port und Richtung ist Firewall-Fehlersuche ungenau. --- **Quelle bestimmen** Die Quelle ist das System, das die Verbindung startet. Beispiele: Client im LAN externer Benutzer im Internet Server in der DMZ VPN-Client Monitoring-Server Admin-PC Anwendungssystem Wichtig: Die tatsächliche Quell-IP kann durch NAT verändert werden. Merksatz: Quelle = wer startet die Verbindung? --- **Ziel bestimmen** Das Ziel ist das System oder der Dienst, der erreicht werden soll. Beispiele: Webserver Datenbankserver Reverse Proxy Mailgateway DNS-Server SMB-Freigabe VPN-Gateway RDP-Server Wichtig: Bei DNS-Namen muss geprüft werden, auf welche IP-Adresse der Name wirklich zeigt. Merksatz: Ziel = welches System soll erreicht werden? --- **Port und Protokoll bestimmen** Ein Port allein reicht nicht. Man muss auch wissen: TCP oder UDP? Beispiele: | Dienst | Protokoll | |---|---| | HTTPS | TCP 443 | | DNS | UDP/TCP 53 | | NTP | UDP 123 | | SMB | TCP 445 | | SSH | TCP 22 | | RDP | TCP 3389 | | SNMP | UDP 161 | | HTTP/3 | UDP 443 | Merksatz: TCP 443 und UDP 443 sind unterschiedliche Dinge. --- **Richtung bestimmen** Firewall-Regeln sind richtungsabhängig. Beispiele: LAN → WAN WAN → DMZ DMZ → LAN VPN → Servernetz Managementnetz → DMZ Gastnetz → Internet Ein häufiger Fehler ist, eine Regel in der falschen Richtung anzulegen. Merksatz: Regelrichtung nach dem Verbindungsaufbau bestimmen. --- **Zonen bestimmen** Viele Firewalls arbeiten mit Zonen. Beispiele: LAN WAN DMZ VPN Gastnetz IoT-Netz Servernetz Managementnetz Eine Regel muss zur richtigen Zone passen. Beispiel: WAN → DMZ ist nicht dasselbe wie DMZ → WAN. Merksatz: Firewall-Regeln gelten zwischen Zonen oder Interfaces. --- **DNS zuerst prüfen** Viele vermeintliche Firewall-Probleme sind eigentlich DNS-Probleme. Beispiele: Domain zeigt auf falsche öffentliche IP. Interner DNS zeigt auf externe IP. Split DNS ist falsch. DNS-Cache enthält alten Eintrag. AAAA-Record zeigt auf nicht erreichbare IPv6-Adresse. CNAME zeigt auf falschen Namen. Merksatz: Falsche DNS-Auflösung führt zur falschen Zieladresse. --- **Routing prüfen** Firewall-Regeln helfen nicht, wenn kein gültiger Weg zum Ziel existiert. Zu prüfen: Gibt es eine Route zum Zielnetz? Gibt es einen Rückweg? Ist das richtige Gateway eingetragen? Geht der Rückverkehr über dieselbe Firewall? Gibt es asymmetrisches Routing? Ist ein VPN-Routing beteiligt? Merksatz: Routing bestimmt den Weg, Firewall erlaubt oder blockiert ihn. --- **NAT prüfen** Wenn NAT beteiligt ist, muss geprüft werden: Wird die richtige Quelladresse übersetzt? Wird die richtige Zieladresse übersetzt? Stimmt der externe Port? Stimmt der interne Port? Stimmt TCP oder UDP? Zeigt NAT auf das richtige interne Ziel? Gibt es mehrere NAT-Regeln? Greift eine alte Regel vorher? Merksatz: NAT-Fehler entstehen oft durch falsches Ziel, falschen Port oder falsche Reihenfolge. --- **Firewall-Regel prüfen** Bei der Firewall-Regel prüft man: Quelle korrekt? Ziel korrekt? Dienst korrekt? Protokoll korrekt? Port korrekt? Richtung korrekt? Zone korrekt? Regel aktiv? Regel an richtiger Position? Logging aktiv? Wird die Regel überhaupt getroffen? Merksatz: Die tatsächlich getroffene Regel ist wichtiger als die gedachte Regel. --- **Regelreihenfolge prüfen** Viele Firewalls arbeiten von oben nach unten. Die erste passende Regel entscheidet. Problem: Eine allgemeine Blockregel kann eine spätere Erlaubnisregel verdecken. Beispiel: Regel 1: DMZ → LAN any blockieren Regel 2: DMZ-Webserver → DB-Server TCP 5432 erlauben Wenn Regel 1 zuerst greift, funktioniert Regel 2 nicht. Merksatz: Spezifische Erlaubnis vor allgemeine Blockregel setzen. --- **Logs prüfen** Firewall-Logs sind bei der Fehlersuche besonders wichtig. Sie zeigen: Quelle Ziel Port Protokoll Aktion Regelname Zeit Interface Zone NAT-Übersetzung Typische Aktionen im Log: allowed denied dropped rejected Merksatz: Logs zeigen, ob die Firewall erlaubt oder blockiert. --- **Keine Logs sichtbar** Wenn keine Logs sichtbar sind, kann das bedeuten: Verkehr kommt gar nicht bei der Firewall an. Falsche Firewall wird geprüft. Falsches Interface wird geprüft. Logging ist für Regel deaktiviert. DNS zeigt auf anderes Ziel. Routing geht anderen Weg. Client sendet gar keine Anfrage. Provider oder vorgeschaltetes Gerät blockiert. Merksatz: Kein Logeintrag heißt nicht automatisch: Firewall ist nicht beteiligt. --- **Dienst auf Zielsystem prüfen** Wenn Firewall und NAT korrekt aussehen, muss der Dienst selbst geprüft werden. Fragen: Läuft der Dienst? Lauscht der Dienst auf dem richtigen Port? Lauscht der Dienst auf der richtigen IP-Adresse? Blockiert die Host-Firewall? Gibt es Anwendungslogs? Antwortet der Dienst korrekt? Ist das Zertifikat passend? Ist die Anwendung richtig konfiguriert? Merksatz: Erlaubter Port heißt nicht, dass der Dienst funktioniert. --- **Host-Firewall prüfen** Neben der zentralen Firewall kann auch das Zielsystem selbst blockieren. Beispiele: Windows Defender Firewall Linux nftables iptables ufw firewalld lokale Sicherheitssoftware Cloud Security Group Typisches Fehlerbild: Netzwerkfirewall erlaubt, aber Zielsystem lehnt ab oder antwortet nicht. Merksatz: Auch die lokale Firewall des Zielsystems prüfen. --- **Rückweg prüfen** Eine Verbindung braucht Hinweg und Rückweg. Wenn der Rückweg fehlt, funktioniert die Verbindung nicht. Mögliche Ursachen: falsches Gateway falsche Route asymmetrisches Routing NAT-Zuordnung fehlt Antwort geht an falsche Firewall Zielsystem antwortet über anderes Interface Merksatz: Verbindung funktioniert nur, wenn Anfrage und Antwort den passenden Weg haben. --- **Asymmetrisches Routing** Asymmetrisches Routing bedeutet: Hinweg und Rückweg laufen über unterschiedliche Wege. Bei Stateful Firewalls ist das problematisch, weil die Firewall den Verbindungszustand nur auf einem Weg sieht. Folge: Antwortpakete können als ungültig blockiert werden. Merksatz: Stateful Firewalls brauchen zusammenpassenden Hin- und Rückweg. --- **Typisches Szenario: Externer Webdienst nicht erreichbar** Beispiel: Benutzer im Internet kann https://wiki.firma.de nicht öffnen. Prüfreihenfolge: 1. DNS zeigt auf richtige öffentliche IP? 2. Öffentliche IP gehört wirklich zum Anschluss? 3. Kein CGNAT? 4. Portweiterleitung TCP 443 korrekt? 5. Firewall-Regel WAN → DMZ oder WAN → Reverse Proxy korrekt? 6. Reverse Proxy erreichbar? 7. Backend erreichbar? 8. Zertifikat gültig? 9. Webserver-Logs prüfen. 10. Firewall-Logs prüfen. Merksatz: Öffentlicher Webdienst braucht DNS, NAT, Firewall, Proxy, Backend und Zertifikat. --- **Typisches Szenario: Intern funktioniert, extern nicht** Wenn ein Dienst intern funktioniert, aber extern nicht, liegen Ursachen oft bei: externem DNS öffentlicher IP Portweiterleitung Firewall-Regel WAN → DMZ CGNAT Providerblockade Reverse Proxy Zertifikat Dienstbindung nur auf interne IP Merksatz: Intern funktioniert, extern nicht: externe Erreichbarkeit prüfen. --- **Typisches Szenario: Extern funktioniert, intern nicht** Wenn ein Dienst extern funktioniert, aber intern über denselben Namen nicht, liegen Ursachen oft bei: Hairpin NAT fehlt Split DNS fehlt internes DNS zeigt falsch interne Firewall blockiert Zertifikat passt intern nicht interner Client geht falschen Weg Merksatz: Extern funktioniert, intern nicht: Hairpin NAT oder Split DNS prüfen. --- **Typisches Szenario: Portweiterleitung funktioniert nicht** Mögliche Ursachen: - falsche öffentliche IP - CGNAT - Double NAT - NAT-Regel fehlt - NAT-Regel zeigt auf falschen Host - falscher externer Port - falscher interner Port - TCP/UDP verwechselt - Firewall-Regel fehlt - Host-Firewall blockiert - Dienst läuft nicht - DNS zeigt falsch - Test aus internem Netz ohne Hairpin NAT Merksatz: Portweiterleitung braucht korrekte öffentliche IP, NAT, Firewall und Dienst. --- **Typisches Szenario: 502 Bad Gateway** Ein 502-Fehler tritt häufig bei Reverse Proxys auf. Mögliche Ursachen: Backend läuft nicht. Backend-Port falsch. Backend-Protokoll falsch. DNS-Name des Backends falsch. Container oder Server nicht erreichbar. Firewall blockiert Proxy → Backend. Backend antwortet ungültig. TLS zum Backend falsch konfiguriert. Merksatz: 502 bedeutet oft: Proxy erreicht Backend nicht korrekt. --- **Typisches Szenario: Zugriff auf Datenbank aus DMZ geht nicht** Beispiel: Webserver in DMZ soll Datenbank im Servernetz erreichen. Prüfen: Quelle: Webserver in DMZ Ziel: Datenbankserver im Servernetz Dienst: Datenbankport Richtung: DMZ → Servernetz Zusätzlich: Datenbankdienst läuft? Datenbank lauscht auf richtiger IP? Host-Firewall erlaubt? Benutzerrechte in Datenbank korrekt? Rückweg vorhanden? Merksatz: Datenbankzugriff aus DMZ braucht enge, gezielte Regeln. --- **Typisches Szenario: VPN-Benutzer erreicht internen Server nicht** Mögliche Ursachen: - VPN-Verbindung nicht korrekt aufgebaut - VPN-Client bekommt falsche IP - Route zum internen Netz fehlt - Firewall-Regel VPN → Servernetz fehlt - DNS für interne Namen fehlt - Split Tunnel falsch - Zielserver-Firewall blockiert - Benutzergruppe nicht berechtigt - NAT im VPN falsch Merksatz: VPN-Probleme mit Adresse, Route, DNS, Firewall und Berechtigung prüfen. --- **Typisches Szenario: Gastnetz erreicht LAN** Das ist ein Sicherheitsproblem. Mögliche Ursachen: - Firewall-Regel zu offen - falsche Zonen-Zuordnung - VLAN falsch konfiguriert - Gastnetz und LAN im selben Netz - Any-Any-Regel - Routing ohne Filter - alte Testregel vergessen Merksatz: Gastnetz darf nicht ins interne LAN führen. --- **Typisches Szenario: IoT-Geräte erreichen interne Server** Auch das kann ein Risiko sein. Mögliche Ursachen: - IoT-Netz nicht getrennt - Firewall-Regel zu breit - Geräte im falschen VLAN - mDNS oder Broadcast-Freigaben unkontrolliert - Any-Regel aktiv - fehlende Segmentierung Besser: IoT → Internet nur nötig IoT → LAN blockieren Admin-Netz → IoT gezielt erlauben Merksatz: IoT-Geräte nur kontrolliert kommunizieren lassen. --- **Typisches Szenario: DNS funktioniert nicht** Mögliche Ursachen: - UDP 53 blockiert - TCP 53 blockiert - falscher DNS-Server - DNS-Server nicht erreichbar - Firewall erlaubt nur externe DNS - interne DNS-Zone fehlt - Split DNS falsch - DNS-Cache veraltet - DHCP verteilt falschen DNS Merksatz: DNS braucht je nach Fall UDP und TCP 53. --- **Typisches Szenario: NTP funktioniert nicht** Mögliche Ursachen: - UDP 123 blockiert - falscher Zeitserver - DNS zum Zeitserver fehlerhaft - Zeitabweichung zu groß - NTP-Dienst läuft nicht - Firewall erlaubt nur TCP statt UDP - VM-Zeitquelle widerspricht NTP Folgeprobleme: Zertifikatsfehler Kerberos-Probleme falsche Logs Monitoringfehler Merksatz: NTP-Probleme können viele Folgefehler erzeugen. --- **Typisches Szenario: RDP funktioniert nicht** Mögliche Ursachen: - TCP 3389 blockiert - RDP am Zielsystem deaktiviert - Benutzer nicht berechtigt - Zielsystem ausgeschaltet - VPN nicht verbunden - Firewall-Regel fehlt - Host-Firewall blockiert - NLA-Problem - DNS zeigt falsch Sicherheit: RDP nicht direkt aus dem Internet veröffentlichen. Merksatz: RDP besser über VPN oder Gateway nutzen. --- **Typisches Szenario: SSH funktioniert nicht** Mögliche Ursachen: - TCP 22 blockiert - SSH-Dienst läuft nicht - SSH läuft auf anderem Port - falscher Benutzer - falscher Schlüssel - Passwortlogin deaktiviert - Host-Firewall blockiert - Zugriff nur aus Managementnetz erlaubt - Fail2ban blockiert Quelle Merksatz: SSH mit Port, Dienst, Benutzer, Schlüssel und Firewall prüfen. --- **Typisches Szenario: Mailserver empfängt keine Mails** Mögliche Ursachen: - MX-Record falsch - DNS zeigt falsch - TCP 25 blockiert - NAT-Regel fehlt - Firewall-Regel fehlt - Mailgateway down - Spamfilter lehnt ab - Zertifikat oder TLS-Problem - Provider blockiert Port 25 - Mailserver nicht zuständig für Domain Merksatz: Mail-Empfang braucht MX, DNS, SMTP, Firewall und Mailserverkonfiguration. --- **Typisches Szenario: Anwendung funktioniert nur teilweise** Mögliche Ursachen: - Hauptport erlaubt, Zusatzport fehlt - API erreichbar, Datenbank nicht erreichbar - Weboberfläche erreichbar, WebSocket blockiert - DNS erlaubt, NTP blockiert - FTP-Login geht, Datenports fehlen - Authentifizierung geht, LDAP-Gruppenabfrage blockiert Merksatz: Manche Anwendungen brauchen mehr als nur einen Port. --- **TCP und UDP nicht verwechseln** Ein häufiger Fehler ist, nur den Port zu betrachten. Beispiele: DNS kann UDP 53 und TCP 53 brauchen. NTP nutzt UDP 123, nicht TCP 123. SNMP nutzt UDP 161, nicht TCP 161. HTTP/3 nutzt UDP 443, während HTTPS klassisch TCP 443 nutzt. Merksatz: Portnummer ohne Protokoll ist unvollständig. --- **ICMP bei Fehlersuche** ICMP wird oft für Diagnose genutzt. Beispiele: Ping Traceroute Ziel nicht erreichbar Time Exceeded Fragmentierung nötig ICMP komplett zu blockieren, kann Fehlersuche erschweren und Netzwerkprobleme verdecken. Merksatz: ICMP ist mehr als Ping. --- **Ping reicht nicht aus** Ping zeigt nur, ob ICMP-Echo funktioniert. Ping sagt nicht: ob TCP 443 offen ist ob HTTP funktioniert ob Anmeldung klappt ob DNS korrekt ist ob Zertifikat passt ob Anwendung gesund ist Merksatz: Ping ist nur ein erster Hinweis, kein vollständiger Diensttest. --- **Porttest reicht nicht aus** Ein erfolgreicher Porttest zeigt: Zielport ist erreichbar. Er zeigt nicht automatisch: Anwendung antwortet korrekt Authentifizierung klappt Datenformat stimmt Zertifikat passt Reverse Proxy leitet richtig weiter Benutzer hat Rechte Merksatz: Offener Port heißt nicht: Anwendung funktioniert. --- **Typische Testwerkzeuge** | Werkzeug | Zweck | |---|---| | ping | einfache Erreichbarkeit prüfen | | traceroute / tracert | Weg zum Ziel prüfen | | nslookup | DNS prüfen | | dig | DNS detaillierter prüfen | | curl | HTTP/HTTPS/API testen | | nc | TCP/UDP-Port testen | | Test-NetConnection | Windows-Porttest | | openssl s_client | TLS-Zertifikat prüfen | | tcpdump | Paketmitschnitt | | Wireshark | Paketmitschnitt analysieren | | Firewall-Log | erlaubten oder blockierten Verkehr prüfen | | Serverlog | Dienstfehler prüfen | Merksatz: Werkzeug nach Fragestellung auswählen. --- **Paketmitschnitt** Ein Paketmitschnitt kann zeigen, ob Verkehr wirklich ankommt. Man sieht zum Beispiel: ARP DNS TCP-Handshake TLS-Handshake ICMP DHCP Wiederholungen Timeouts Reset-Pakete Wichtig: Bei TLS sieht man den Inhalt nicht einfach im Klartext. Merksatz: Paketmitschnitt zeigt den echten Verkehr. --- **TCP-Handshake prüfen** Bei TCP ist der Verbindungsaufbau wichtig. Vereinfacht: SYN SYN-ACK ACK Fehlerbilder: Nur SYN: Ziel antwortet nicht oder Firewall blockiert. SYN und RST: Ziel lehnt aktiv ab oder Dienst nicht offen. SYN, SYN-ACK, ACK: TCP-Verbindung wurde aufgebaut. Merksatz: TCP-Handshake zeigt, ob eine TCP-Verbindung entsteht. --- **Timeout** Timeout bedeutet: Es kommt keine Antwort innerhalb der erwarteten Zeit. Mögliche Ursachen: - Firewall droppt Pakete - Routingproblem - Ziel nicht erreichbar - Dienst antwortet nicht - Rückweg fehlt - Paket geht an falsches Ziel - Provider blockiert Merksatz: Timeout bedeutet oft: keine oder keine passende Antwort. --- **Connection Refused** Connection refused bedeutet: Zielsystem ist erreichbar, aber der Dienst nimmt auf dem Port keine Verbindung an. Mögliche Ursachen: - Dienst läuft nicht - falscher Port - Dienst lauscht nur lokal - Host-Firewall lehnt aktiv ab - Anwendung nicht gestartet Merksatz: Connection refused deutet auf Zielsystem oder Dienst hin. --- **Reset** Ein TCP Reset beendet oder verweigert eine Verbindung aktiv. Mögliche Ursachen: - Dienst lehnt Verbindung ab - Firewall sendet Reset - Anwendung beendet Verbindung - falsches Protokoll auf Port - Sicherheitsregel greift Merksatz: Reset ist eine aktive Ablehnung oder Beendigung. --- **Fehlersuche mit Logs kombinieren** Am besten kombiniert man: Client-Fehler DNS-Ergebnis Porttest Firewall-Log NAT-Log Serverlog Anwendungstest Beispiel: Client meldet Timeout. Firewall-Log zeigt Drop. Ursache: Firewall-Regel fehlt oder blockiert. Oder: Client meldet 502. Firewall erlaubt. Reverse-Proxy-Log zeigt Backend nicht erreichbar. Ursache: Backend oder interne Regel prüfen. Merksatz: Mehrere Hinweise zusammen ergeben die Ursache. --- **Fehler nach Änderung** Wenn ein Problem direkt nach einer Änderung auftritt, prüft man zuerst diese Änderung. Beispiele: neue Firewall-Regel NAT geändert DNS geändert Zertifikat erneuert Reverse Proxy angepasst Dienst neu gestartet Server-IP geändert VLAN geändert VPN-Gruppe geändert Update installiert Merksatz: Nach Änderung zuerst Änderung prüfen. --- **Änderungen dokumentieren** Firewall- und NAT-Änderungen sollten dokumentiert werden. Wichtige Angaben: - Datum - Zweck - Quelle - Ziel - Port - Protokoll - Richtung - NAT-Ziel - Verantwortlicher - Ticket - Testergebnis - Rollback-Möglichkeit Merksatz: Gute Dokumentation verkürzt spätere Fehlersuche. --- **Rollback** Rollback bedeutet: Änderung zurücknehmen, wenn sie Probleme verursacht. Bei Firewall-Änderungen wichtig: vorherigen Zustand kennen Backup der Konfiguration haben Wartungsfenster beachten Zugriff auf Firewall nicht selbst aussperren Notfallzugang sichern Merksatz: Vor kritischen Änderungen Rückweg planen. --- **Sich nicht selbst aussperren** Bei Firewall-Änderungen kann man sich selbst den Zugriff nehmen. Beispiele: Admin-Regel gelöscht. Managementnetz blockiert. VPN-Regel falsch gesetzt. Weboberfläche der Firewall nicht mehr erreichbar. Vorbeugung: Konfiguration sichern. lokalen Zugriff bereithalten. Änderung mit Zeitplan oder Rollback absichern. Managementzugriff nicht ungetestet ändern. Merksatz: Managementzugriff besonders vorsichtig ändern. --- **Checkliste: Firewall-Fehlersuche** 1. Fehlerbild genau aufnehmen. 2. Quelle bestimmen. 3. Ziel bestimmen. 4. Port und Protokoll bestimmen. 5. Richtung und Zone bestimmen. 6. DNS prüfen. 7. Routing prüfen. 8. NAT prüfen. 9. Firewall-Regel prüfen. 10. Regelreihenfolge prüfen. 11. Firewall-Logs prüfen. 12. Zielsystem-Firewall prüfen. 13. Dienststatus prüfen. 14. Anwendung testen. 15. Rückweg prüfen. 16. letzte Änderungen prüfen. 17. Ergebnis dokumentieren. Merksatz: Firewall-Fehlersuche ist eine Kette, kein einzelner Test. --- **Was man nicht vorschnell tun sollte** Nicht sofort: Any-Any-Regel erstellen. Firewall komplett deaktivieren. alle Ports öffnen. DMZ ins LAN freigeben. Adminport ins Internet öffnen. Logs ignorieren. DNS ungeprüft lassen. NAT und Firewall verwechseln. Warum? Solche Maßnahmen können Sicherheitslücken erzeugen und die eigentliche Ursache verdecken. Merksatz: Nicht Sicherheit opfern, nur um schnell einen Test zu machen. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wie geht man bei Firewall-Fehlersuche systematisch vor? - Warum reichen Ping und Porttest nicht aus? - Warum muss man Quelle, Ziel, Port und Richtung kennen? - Warum ist DNS bei Firewallproblemen relevant? - Warum muss NAT zusätzlich zur Firewall geprüft werden? - Warum kann eine Portweiterleitung trotz NAT-Regel nicht funktionieren? - Was bedeutet Timeout? - Was bedeutet Connection Refused? - Was ist asymmetrisches Routing? - Warum sind Firewall-Logs wichtig? - Warum können interne und externe Tests unterschiedliche Ergebnisse liefern? - Warum sollte man nicht einfach Any-Any erlauben? - Warum ist Dokumentation bei Firewall-Regeln wichtig? --- **Typische Prüfungsfallen** Ping prüft nicht den Dienst. Porttest prüft nicht die Anwendung. DNS kann wie ein Firewallproblem wirken. NAT-Regel ist nicht Firewall-Regel. Firewall-Regel ist nicht NAT-Regel. TCP und UDP nicht verwechseln. Regelrichtung beachten. Zone beachten. Regelreihenfolge beachten. Rückweg beachten. Stateful Firewalls brauchen Verbindungszustand. Asymmetrisches Routing kann Verbindungen stören. Timeout und Connection Refused bedeuten nicht dasselbe. Host-Firewall zusätzlich prüfen. Dienst muss wirklich laufen. Logs sind zentrale Hinweise. Keine Any-Any-Regel als Dauerlösung. Änderungen dokumentieren. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Quelle | System, das Verbindung startet | | Ziel | System, das erreicht werden soll | | Richtung | Weg zwischen Zonen oder Interfaces | | Zone | Sicherheitsbereich der Firewall | | NAT | Adressübersetzung | | PAT | Port- und Adressübersetzung | | Portweiterleitung | externer Port wird intern weitergeleitet | | Rückweg | Antwortweg zurück zur Quelle | | asymmetrisches Routing | Hin- und Rückweg sind unterschiedlich | | Timeout | keine Antwort innerhalb der Zeit | | Connection Refused | Ziel lehnt Verbindung aktiv ab | | TCP Reset | aktive Verbindungsbeendigung | | Firewall-Log | Protokoll erlaubter oder blockierter Verbindungen | | Host-Firewall | Firewall auf dem Zielsystem | | Hairpin NAT | interner Zugriff über öffentliche Adresse | | Split DNS | intern und extern unterschiedliche DNS-Antwort | | CGNAT | Provider-NAT, oft ohne eingehende Ports | | Rollback | Änderung zurücknehmen | | Any-Any | sehr breite Erlaubnisregel | --- **IHK-sichere Kurzformulierung** Bei der Fehlersuche an Firewalls, NAT und DMZ müssen Quelle, Ziel, Port, Protokoll, Richtung und Zone genau bestimmt werden. Zusätzlich sind DNS, Routing, NAT-Regeln, Firewall-Regeln, Regelreihenfolge, Host-Firewall, Dienststatus, Rückweg und Logs zu prüfen. Eine NAT-Regel übersetzt Adressen oder Ports, ersetzt aber keine Firewall-Regel. Ein erfolgreicher Ping oder ein offener Port beweist nicht, dass der Anwendungdienst korrekt funktioniert. Typische Ursachen für Fehler sind falsche DNS-Einträge, fehlende Portweiterleitungen, blockierende Firewall-Regeln, falsche Richtung, TCP/UDP-Verwechslung, fehlender Rückweg, CGNAT, Double NAT oder ein nicht laufender Dienst. --- **Merksätze** Erst Quelle bestimmen. Dann Ziel bestimmen. Dann Port und Protokoll bestimmen. Dann Richtung und Zone prüfen. DNS zuerst nicht vergessen. Routing findet den Weg. Firewall erlaubt oder blockiert den Weg. NAT übersetzt Adressen oder Ports. NAT ersetzt keine Firewall-Regel. Firewall-Regel ersetzt keine NAT-Regel. TCP und UDP nicht verwechseln. Regelreihenfolge beachten. Spezifisch vor allgemein. Logs zeigen, welche Regel greift. Kein Log kann bedeuten, dass Verkehr gar nicht ankommt. Host-Firewall zusätzlich prüfen. Dienst muss wirklich laufen. Rückweg muss stimmen. Timeout bedeutet: keine passende Antwort. Connection Refused bedeutet: Ziel lehnt aktiv ab. Ping reicht nicht aus. Porttest reicht nicht aus. Offener Port heißt nicht: Anwendung funktioniert. Intern und extern getrennt testen. Hairpin NAT oder Split DNS bei internen Tests beachten. CGNAT kann Portweiterleitungen verhindern. Any-Any nicht als schnelle Dauerlösung verwenden. Änderungen dokumentieren. Vor kritischen Änderungen Rollback planen. # 11.6 Merksätze und Prüfungswissen zu Firewalls, NAT und DMZ Diese Seite fasst die wichtigsten Inhalte zu Firewalls, NAT, PAT, Portweiterleitung und DMZ zusammen. Diese Themen gehören zu den wichtigsten Grundlagen der Netzwerksicherheit. Wichtige Begriffe: - Firewall - Regelwerk - Paketfilter - Stateful Inspection - NAT - PAT - Portweiterleitung - DMZ - Sicherheitszone - Default Deny - Allow - Drop - Reject - Source NAT - Destination NAT - Hairpin NAT - Split DNS - CGNAT Merksatz: Firewall kontrolliert Verkehr. NAT übersetzt Adressen. DMZ trennt öffentliche Dienste vom internen Netz. --- **Grundidee** Firewalls, NAT und DMZ haben unterschiedliche Aufgaben. Firewall: entscheidet, ob Verkehr erlaubt oder blockiert wird. NAT: übersetzt IP-Adressen. PAT: übersetzt IP-Adressen und Ports. DMZ: trennt öffentlich erreichbare Dienste vom internen LAN. Merksatz: Firewall, NAT und DMZ nicht miteinander verwechseln. --- **Firewall** Eine Firewall kontrolliert Netzwerkverkehr. Sie prüft je nach Art zum Beispiel: - Quell-IP-Adresse - Ziel-IP-Adresse - Protokoll - Quellport - Zielport - Richtung - Interface - Zone - Verbindungsstatus - Anwendung Merksatz: Firewall = kontrollierter Übergang zwischen Netzen. --- **Firewall-Regel** Eine Firewall-Regel beschreibt, welcher Verkehr erlaubt oder blockiert wird. Typische Bestandteile: - Aktion - Quelle - Ziel - Dienst - Protokoll - Port - Richtung - Zone - Kommentar - Logging Merksatz: Firewall-Regel = Quelle, Ziel, Dienst und Aktion. --- **Aktionen einer Firewall** | Aktion | Bedeutung | |---|---| | Allow | Verkehr erlauben | | Deny | Verkehr blockieren | | Drop | Paket still verwerfen | | Reject | Paket aktiv ablehnen | | Log | Treffer protokollieren | Merksatz: Allow erlaubt. Drop schweigt. Reject antwortet. --- **Drop und Reject** Drop bedeutet: Paket wird ohne Antwort verworfen. Reject bedeutet: Paket wird aktiv abgelehnt, und der Absender erhält eine Antwort. Typische Wirkung: Drop führt oft zu Timeout. Reject führt oft zu schneller Fehlermeldung. Merksatz: Drop = keine Antwort. Reject = aktive Ablehnung. --- **Paketfilter** Ein Paketfilter prüft vor allem: - IP-Adressen - Protokoll - Ports - Richtung - Interface Er arbeitet hauptsächlich auf Schicht 3 und 4. Merksatz: Paketfilter prüft IP und Port. --- **Stateful Firewall** Eine Stateful Firewall merkt sich Verbindungen. Sie erkennt: neues Paket bestehende Verbindung zugehörige Antwort ungültiges Paket Vorteil: Rückverkehr zu erlaubten Verbindungen kann automatisch zugelassen werden. Merksatz: Stateful Firewall kennt den Verbindungszustand. --- **Stateful Inspection** Stateful Inspection bedeutet: Die Firewall prüft, ob Pakete zu einer bekannten Verbindung gehören. Besonders wichtig bei TCP: SYN SYN-ACK ACK Merksatz: Stateful Inspection prüft Verbindungszusammenhang. --- **Stateless Firewall** Eine Stateless Firewall betrachtet Pakete einzeln. Sie merkt sich keinen Verbindungszustand. Folge: Hin- und Rückverkehr müssen genauer einzeln geregelt werden. Merksatz: Stateless = jedes Paket einzeln. --- **Default Deny** Default Deny bedeutet: Alles ist verboten, was nicht ausdrücklich erlaubt wurde. Das ist ein wichtiges Sicherheitsprinzip. Vorteil: unbekannter oder unnötiger Verkehr wird nicht automatisch erlaubt. Merksatz: Erst alles blockieren, dann gezielt erlauben. --- **Default Allow** Default Allow bedeutet: Alles ist erlaubt, was nicht ausdrücklich verboten wurde. Das ist oft unsicherer, weil vergessene oder neue Dienste automatisch erreichbar sein können. Merksatz: Default Allow ist bequem, aber riskant. --- **Regelreihenfolge** Viele Firewalls prüfen Regeln von oben nach unten. Die erste passende Regel entscheidet. Deshalb ist wichtig: spezifische Regeln vor allgemeine Regeln Beispiel: Erlaube Admin-PC → Server SSH vor: Blockiere restliches SSH Merksatz: Die erste passende Regel gewinnt. --- **Spezifisch vor allgemein** Spezifische Regeln beschreiben einen engen Fall. Allgemeine Regeln beschreiben einen breiten Fall. Richtig: erst Ausnahme erlauben, dann allgemein blockieren. Falsch: zuerst allgemein blockieren, dann Ausnahme erlauben. Merksatz: Spezifisch vor allgemein. --- **Any und Any-Any** Any bedeutet: beliebig Any-Any bedeutet meistens: Quelle beliebig Ziel beliebig Dienst beliebig Das ist sehr weit geöffnet und meist gefährlich. Merksatz: Any-Any vermeiden. --- **Firewall-Zonen** Eine Zone ist ein Sicherheitsbereich. Typische Zonen: | Zone | Zweck | |---|---| | WAN | Internet oder externes Netz | | LAN | internes Clientnetz | | DMZ | öffentliche Dienste | | Servernetz | interne Server | | Managementnetz | Administration | | Gastnetz | Gäste | | IoT-Netz | Geräte mit eingeschränktem Vertrauen | | VPN-Zone | entfernte Benutzer nach VPN-Einwahl | Merksatz: Zonen trennen Netze nach Schutzbedarf. --- **LAN, WAN und DMZ** LAN: internes Netz WAN: externes Netz oder Internet DMZ: eigenes Netz für öffentlich erreichbare Dienste Merksatz: LAN innen. WAN außen. DMZ dazwischen. --- **DMZ** DMZ steht für: Demilitarized Zone Eine DMZ enthält Dienste, die von außen erreichbar sein müssen. Beispiele: - Webserver - Reverse Proxy - Mailgateway - VPN-Gateway - öffentlicher DNS-Server - Bastion Host Merksatz: DMZ = separates Netz für öffentliche Dienste. --- **Zweck einer DMZ** Eine DMZ schützt das interne LAN. Wenn ein öffentlich erreichbarer Server kompromittiert wird, soll der Angreifer nicht direkt ins interne Netz gelangen. Merksatz: DMZ begrenzt Schaden bei öffentlichen Diensten. --- **DMZ-Regelprinzip** Typische Regelidee: Internet → DMZ: nur notwendige öffentliche Dienste erlauben Internet → LAN: blockieren DMZ → LAN: nur zwingend notwendige Verbindungen erlauben Managementnetz → DMZ: Administration gezielt erlauben Merksatz: DMZ darf keine freie Brücke ins LAN sein. --- **Reverse Proxy in der DMZ** Ein Reverse Proxy nimmt externe Anfragen an und leitet sie an interne Dienste weiter. Vorteile: - zentrale TLS-Verwaltung - mehrere Webdienste über eine öffentliche IP - weniger direkte Veröffentlichung interner Server - bessere Kontrolle - bessere Protokollierung Merksatz: Reverse Proxy bündelt und schützt Webzugriffe. --- **Bastion Host** Ein Bastion Host ist ein besonders abgesicherter Sprungserver. Er dient dazu, administrative Zugriffe zu bündeln und zu kontrollieren. Typisch: Admin → Bastion Host → Zielsystem Merksatz: Bastion Host = abgesicherter Zugangspunkt für Administration. --- **NAT** NAT steht für: Network Address Translation NAT übersetzt IP-Adressen. Typischer Einsatz: private IPv4-Adresse wird beim Zugriff ins Internet in öffentliche IPv4-Adresse übersetzt. Merksatz: NAT übersetzt IP-Adressen. --- **Warum NAT bei IPv4 wichtig ist** Private IPv4-Adressen sind im Internet nicht direkt geroutet. NAT ermöglicht, dass interne Geräte mit privaten Adressen trotzdem ins Internet können. Außerdem spart NAT öffentliche IPv4-Adressen. Merksatz: NAT ermöglicht Internetzugriff mit privaten IPv4-Adressen. --- **Private IPv4-Adressbereiche** | Bereich | CIDR | |---|---| | 10.0.0.0 bis 10.255.255.255 | 10.0.0.0/8 | | 172.16.0.0 bis 172.31.255.255 | 172.16.0.0/12 | | 192.168.0.0 bis 192.168.255.255 | 192.168.0.0/16 | Diese Bereiche sind für interne Netze vorgesehen. Merksatz: Private IPv4-Adressen werden im Internet nicht direkt geroutet. --- **Öffentliche IP-Adresse** Eine öffentliche IP-Adresse ist im Internet routbar. Sie wird zum Beispiel vom Provider zugewiesen. Interne Geräte sind meist über NAT hinter dieser öffentlichen Adresse sichtbar. Merksatz: Öffentliche IP-Adresse ist im Internet erreichbar. --- **Source NAT** Source NAT ändert die Quelladresse. Typischer Fall: Client im LAN baut Verbindung ins Internet auf. Vorher: Quelle: private IP Nachher: Quelle: öffentliche IP des Routers oder der Firewall Merksatz: Source NAT ändert die Quelle. --- **Destination NAT** Destination NAT ändert die Zieladresse. Typischer Fall: externer Zugriff wird an internes Ziel weitergeleitet. Beispiel: öffentliche IP:443 → interner Webserver:443 Merksatz: Destination NAT ändert das Ziel. --- **PAT** PAT steht für: Port Address Translation PAT übersetzt zusätzlich Ports. Dadurch können viele interne Geräte gleichzeitig über eine öffentliche IP-Adresse kommunizieren. Merksatz: PAT = NAT mit Portübersetzung. --- **NAT und PAT unterscheiden** | Begriff | Bedeutung | |---|---| | NAT | IP-Adressen werden übersetzt | | PAT | IP-Adressen und Ports werden übersetzt | | Source NAT | Quelladresse wird geändert | | Destination NAT | Zieladresse wird geändert | | Portweiterleitung | externer Port wird intern weitergeleitet | Merksatz: NAT = Adresse. PAT = Adresse plus Port. --- **Portweiterleitung** Portweiterleitung bedeutet: Ein externer Port wird an ein internes Ziel weitergeleitet. Beispiel: WAN TCP 443 → 192.168.10.20 TCP 443 Portweiterleitung ist eine Form von Destination NAT. Merksatz: Portweiterleitung macht interne Dienste extern erreichbar. --- **Portweiterleitung und Sicherheit** Eine Portweiterleitung erhöht die Angriffsfläche. Warum? Ein interner Dienst wird von außen erreichbar. Deshalb wichtig: - nur notwendige Ports öffnen - Dienste aktuell halten - starke Authentifizierung - TLS nutzen - Logs prüfen - Zugriff einschränken - keine Admin-Dienste direkt veröffentlichen Merksatz: Jeder veröffentlichte Port ist ein Risiko. --- **Was man nicht direkt veröffentlichen sollte** Normalerweise nicht direkt ins Internet: - SMB TCP 445 - RDP TCP 3389 - Telnet TCP 23 - Datenbankports - NAS-Adminoberflächen - Hypervisor-Management - Drucker - interne Adminoberflächen Besser: VPN, Reverse Proxy, Bastion Host, Zero-Trust-Zugriff oder kontrollierte Quellbeschränkung. Merksatz: Interne Admin-Dienste nicht direkt ins Internet öffnen. --- **NAT-Regel und Firewall-Regel unterscheiden** NAT-Regel: Wohin wird Verkehr übersetzt oder weitergeleitet? Firewall-Regel: Darf dieser Verkehr passieren? Beide müssen passen. Beispiel: NAT leitet WAN:443 an Server weiter. Firewall blockiert WAN → Server TCP 443. Ergebnis: Zugriff funktioniert nicht. Merksatz: NAT leitet um. Firewall erlaubt oder blockiert. --- **Routing und Firewall unterscheiden** Routing entscheidet: welchen Weg ein Paket nimmt. Firewall entscheidet: ob ein Paket erlaubt wird. Beides muss stimmen. Merksatz: Routing findet den Weg. Firewall erlaubt den Weg. --- **Hairpin NAT** Hairpin NAT bedeutet: Ein interner Client greift über die öffentliche Adresse auf einen internen Dienst zu. Beispiel: Client im LAN ruft cloud.firma.de auf. DNS liefert öffentliche IP. Router leitet Verbindung wieder nach innen. Merksatz: Hairpin NAT = intern über öffentliche Adresse. --- **Split DNS** Split DNS liefert intern und extern unterschiedliche DNS-Antworten. Beispiel: cloud.firma.de extern: öffentliche IP cloud.firma.de intern: interne IP Vorteil: interne Clients erreichen den Dienst direkt intern. Merksatz: Split DNS kann Hairpin NAT vermeiden. --- **CGNAT** CGNAT steht für: Carrier Grade NAT Dabei teilt der Provider eine öffentliche IPv4-Adresse auf mehrere Kunden auf. Folge: eingehende Portweiterleitungen funktionieren oft nicht direkt. Merksatz: CGNAT verhindert oft direkte eingehende IPv4-Verbindungen. --- **Double NAT** Double NAT bedeutet: Zwei NAT-Geräte sind hintereinander aktiv. Beispiel: Provider-Router macht NAT. Eigener Router macht NAT. Folge: Portweiterleitungen müssen auf beiden Geräten passen. Merksatz: Double NAT erschwert Portweiterleitungen. --- **Firewall und DNS** DNS ist bei Firewall- und NAT-Themen sehr wichtig. Beispiel: DNS zeigt auf falsche öffentliche IP. Dann erreicht der Client nicht das richtige Ziel. Oder: intern wird ein anderer DNS-Eintrag benötigt als extern. Merksatz: Falsches DNS kann wie ein Firewallproblem aussehen. --- **Firewall und TLS** Ein offener Port 443 bedeutet nicht automatisch, dass HTTPS korrekt funktioniert. Mögliche zusätzliche Probleme: - falsches Zertifikat - Zertifikat abgelaufen - Hostname passt nicht - Reverse Proxy falsch - Backend nicht erreichbar - TLS-Version passt nicht Merksatz: Port 443 offen heißt nicht: HTTPS funktioniert korrekt. --- **Firewall und Rückweg** Eine Verbindung braucht Hinweg und Rückweg. Wenn der Rückweg fehlt, funktioniert die Verbindung nicht. Mögliche Ursachen: - falsches Gateway - fehlende Route - asymmetrisches Routing - NAT-Zuordnung fehlt - Antwort geht über falsches Interface Merksatz: Ohne Rückweg keine funktionierende Verbindung. --- **Asymmetrisches Routing** Asymmetrisches Routing bedeutet: Hinweg und Rückweg laufen über unterschiedliche Wege. Das kann Stateful Firewalls stören, weil sie den Verbindungszustand nur auf einem Weg sehen. Merksatz: Stateful Firewalls brauchen passenden Hin- und Rückweg. --- **Firewall-Logs** Firewall-Logs zeigen, was mit Verkehr passiert. Wichtige Angaben: - Quelle - Ziel - Port - Protokoll - Aktion - Zeit - Regelname - Zone - Interface - NAT-Übersetzung Merksatz: Logs zeigen, ob Verkehr erlaubt oder blockiert wurde. --- **Typische Fehler bei Firewalls** Typische Fehler: - falsche Quelle - falsches Ziel - falscher Port - TCP und UDP verwechselt - falsche Richtung - falsche Zone - falsche Regelreihenfolge - Regel deaktiviert - Host-Firewall blockiert - Dienst läuft nicht - Rückweg fehlt - DNS zeigt falsch Merksatz: Firewall-Fehler sind oft Detailfehler. --- **Typische Fehler bei NAT** Typische Fehler: - NAT-Regel fehlt - falsche öffentliche IP - falsches internes Ziel - falscher interner Port - falscher externer Port - TCP und UDP verwechselt - CGNAT - Double NAT - alte NAT-Regel greift - DNS zeigt auf falsche IP - Hairpin NAT fehlt Merksatz: NAT-Fehler betreffen oft Adresse, Port oder Ziel. --- **Typische Fehler bei DMZ** Typische Fehler: - öffentliche Dienste im LAN statt in DMZ - DMZ darf zu viel ins LAN - Adminzugang aus Internet erlaubt - Firewall-Regel zu breit - Reverse Proxy erreicht Backend nicht - DNS falsch - Zertifikat falsch - ausgehender DMZ-Verkehr ungefiltert - Monitoring fehlt - Logs fehlen Merksatz: DMZ-Fehler sind oft Zonen- oder Regelprobleme. --- **Systematische Fehlersuche** Eine sinnvolle Reihenfolge: 1. Quelle bestimmen. 2. Ziel bestimmen. 3. Port und Protokoll bestimmen. 4. Richtung und Zone bestimmen. 5. DNS prüfen. 6. Routing prüfen. 7. NAT prüfen. 8. Firewall-Regel prüfen. 9. Regelreihenfolge prüfen. 10. Firewall-Logs prüfen. 11. Host-Firewall prüfen. 12. Dienststatus prüfen. 13. Rückweg prüfen. 14. Anwendung testen. 15. Änderungen prüfen. Merksatz: Firewall-Fehlersuche ist eine Verbindungskette. --- **Ping reicht nicht aus** Ping prüft nur ICMP-Erreichbarkeit. Ping sagt nicht: ob TCP 443 offen ist ob HTTPS korrekt funktioniert ob NAT stimmt ob Zertifikat passt ob Anmeldung funktioniert ob Anwendung antwortet Merksatz: Ping ist kein vollständiger Diensttest. --- **Porttest reicht nicht aus** Ein Porttest zeigt nur: Port erreichbar oder nicht erreichbar. Er zeigt nicht automatisch: Anwendung korrekt Zertifikat korrekt Anmeldung korrekt Rechte korrekt Datenformat korrekt Backend korrekt Merksatz: Offener Port heißt nicht: Dienst funktioniert. --- **Timeout** Timeout bedeutet: Es kommt keine Antwort innerhalb der erwarteten Zeit. Mögliche Ursachen: - Firewall droppt - Routingproblem - Dienst antwortet nicht - Rückweg fehlt - falsches Ziel - Provider blockiert Merksatz: Timeout bedeutet oft: keine passende Antwort. --- **Connection Refused** Connection refused bedeutet: Zielsystem ist erreichbar, aber der Dienst nimmt auf dem Port keine Verbindung an. Mögliche Ursachen: - Dienst läuft nicht - falscher Port - Dienst lauscht nur lokal - Host-Firewall lehnt ab Merksatz: Connection refused deutet eher auf Zielsystem oder Dienst hin. --- **Wichtige Testwerkzeuge** | Werkzeug | Zweck | |---|---| | ping | grobe Erreichbarkeit | | traceroute / tracert | Weg zum Ziel | | nslookup | DNS prüfen | | dig | DNS detailliert prüfen | | curl | HTTP/HTTPS testen | | nc | TCP-/UDP-Port testen | | Test-NetConnection | Windows-Porttest | | openssl s_client | TLS prüfen | | tcpdump | Verkehr mitschneiden | | Wireshark | Pakete analysieren | | Firewall-Logs | Regeltreffer prüfen | | Serverlogs | Dienstfehler prüfen | Merksatz: Werkzeug nach Fehlerbild auswählen. --- **Sicherheitsprinzipien** Wichtige Prinzipien: - Default Deny - Least Privilege - nur notwendige Ports öffnen - Adminzugänge nicht öffentlich machen - Zonen trennen - DMZ verwenden - Regeln dokumentieren - temporäre Regeln befristen - Logs aktivieren - Updates einspielen - Monitoring einsetzen Merksatz: Sicherheit entsteht durch mehrere Maßnahmen zusammen. --- **Least Privilege bei Firewall-Regeln** Least Privilege bedeutet: Nur erlauben, was wirklich benötigt wird. Beispiel schlecht: DMZ → LAN any erlauben Beispiel besser: Reverse Proxy → interner Webdienst TCP 8080 erlauben Merksatz: Firewall-Regeln so eng wie möglich setzen. --- **Dokumentation** Firewall- und NAT-Regeln sollten dokumentiert werden. Wichtige Angaben: - Zweck - Quelle - Ziel - Port - Protokoll - Richtung - NAT-Ziel - Verantwortlicher - Ticket - Datum - Ablaufdatum bei temporären Regeln Merksatz: Undokumentierte Regeln werden später zum Risiko. --- **Regelreview** Firewall-Regelwerke sollten regelmäßig geprüft werden. Dabei sucht man: - alte Regeln - ungenutzte Regeln - temporäre Regeln ohne Ablauf - Any-Any-Regeln - zu breite Freigaben - fehlende Kommentare - shadowed rules - redundante Regeln Merksatz: Firewall-Regeln altern und müssen gepflegt werden. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was ist die Aufgabe einer Firewall? - Was ist der Unterschied zwischen Firewall und NAT? - Was ist eine Stateful Firewall? - Was bedeutet Stateful Inspection? - Was bedeutet Default Deny? - Warum ist die Regelreihenfolge wichtig? - Warum sind Any-Any-Regeln gefährlich? - Was ist NAT? - Was ist PAT? - Was ist Source NAT? - Was ist Destination NAT? - Was ist eine Portweiterleitung? - Warum reicht eine NAT-Regel allein nicht aus? - Was ist eine DMZ? - Warum stellt man öffentliche Dienste in eine DMZ? - Warum darf die DMZ nicht frei ins LAN? - Was ist Hairpin NAT? - Was ist Split DNS? - Was ist CGNAT? - Wie geht man bei Firewall-Fehlersuche vor? --- **Typische Prüfungsfallen** Firewall ist nicht NAT. NAT ist nicht Firewall. NAT übersetzt Adressen. PAT übersetzt Adressen und Ports. Portweiterleitung ist Destination NAT. NAT-Regel ersetzt keine Firewall-Regel. Firewall-Regel ersetzt keine NAT-Regel. Routing entscheidet den Weg. Firewall entscheidet die Erlaubnis. DNS kann wie ein Firewallproblem wirken. Port offen heißt nicht: Anwendung funktioniert. TCP und UDP nicht verwechseln. Regelrichtung beachten. Regelreihenfolge beachten. Spezifisch vor allgemein. Default Deny ist sicherer. Any-Any vermeiden. Drop und Reject unterscheiden. DMZ ist nicht LAN. DMZ darf nicht frei ins LAN. Öffentliche Dienste gehören besser in die DMZ. RDP nicht direkt ins Internet öffnen. SMB nicht direkt ins Internet öffnen. CGNAT kann Portweiterleitung verhindern. Hairpin NAT betrifft interne Zugriffe über öffentliche Adresse. Split DNS kann Hairpin NAT vermeiden. Rückweg prüfen. Logs prüfen. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | Firewall | kontrolliert Netzwerkverkehr | | Firewall-Regel | Bedingung mit Aktion | | Paketfilter | prüft IP-Adressen und Ports | | Stateful Firewall | kennt Verbindungszustände | | Stateful Inspection | Prüfung des Verbindungsstatus | | Default Deny | alles blockieren, außer erlaubt | | Allow | erlauben | | Deny | blockieren | | Drop | still verwerfen | | Reject | aktiv ablehnen | | Zone | Sicherheitsbereich | | LAN | internes Netz | | WAN | externes Netz | | DMZ | Netz für öffentliche Dienste | | NAT | Adressübersetzung | | PAT | Adress- und Portübersetzung | | Source NAT | Quelladresse wird geändert | | Destination NAT | Zieladresse wird geändert | | Portweiterleitung | externer Port wird intern weitergeleitet | | Hairpin NAT | interner Zugriff über öffentliche Adresse | | Split DNS | intern und extern unterschiedliche DNS-Antwort | | CGNAT | Provider-NAT für mehrere Kunden | | Double NAT | zwei NAT-Geräte hintereinander | | Reverse Proxy | leitet Webanfragen an Backends | | Bastion Host | abgesicherter Sprungserver | | Any-Any | sehr breite Regel | | Rückweg | Antwortweg zurück zur Quelle | | asymmetrisches Routing | Hin- und Rückweg unterschiedlich | --- **IHK-sichere Gesamtformulierung** Eine Firewall kontrolliert Netzwerkverkehr zwischen Systemen oder Netzbereichen und entscheidet anhand von Regeln, ob Verbindungen erlaubt oder blockiert werden. Typische Kriterien sind Quelle, Ziel, Port, Protokoll, Richtung und Zone. NAT übersetzt IP-Adressen, während PAT zusätzlich Ports übersetzt. Eine Portweiterleitung ist eine Form von Destination NAT und macht einen internen Dienst von außen erreichbar. NAT-Regeln und Firewall-Regeln sind zu unterscheiden und müssen zusammenpassen. Eine DMZ ist ein separates Netz für Dienste, die von außen erreichbar sein müssen. Sie schützt das interne LAN, indem öffentliche Dienste getrennt platziert und Zugriffe zwischen WAN, DMZ und LAN gezielt geregelt werden. --- **Wichtigste Merksätze** Firewall kontrolliert Verkehr. NAT übersetzt Adressen. PAT übersetzt Adressen und Ports. DMZ trennt öffentliche Dienste vom LAN. Firewall ist nicht NAT. NAT ist nicht Firewall. Routing findet den Weg. Firewall erlaubt den Weg. NAT-Regel leitet um. Firewall-Regel erlaubt oder blockiert. Source NAT ändert Quelle. Destination NAT ändert Ziel. Portweiterleitung ist Destination NAT. Private IPv4-Adressen sind intern. Öffentliche IP-Adressen sind im Internet routbar. Default Deny ist sicherer. Die erste passende Regel gewinnt. Spezifisch vor allgemein. Any-Any vermeiden. Drop schweigt. Reject antwortet. Stateful Firewall kennt Verbindungen. Rückweg muss passen. Asymmetrisches Routing kann stören. DMZ ist nicht LAN. DMZ darf nicht frei ins LAN. Öffentliche Dienste gehören besser in die DMZ. Reverse Proxy kann Dienste bündeln. RDP nicht direkt ins Internet öffnen. SMB nicht direkt ins Internet öffnen. CGNAT kann Portweiterleitungen verhindern. Hairpin NAT = intern über öffentliche Adresse. Split DNS = intern andere DNS-Antwort. DNS, NAT, Firewall, Dienst und Logs gemeinsam prüfen.